title: posix pipe as a work queue
body: <p>The normal implementations of a work queue I have seen involve mutexes and condition variables.</p>
  <h3>Consumer:</h3>
  <pre><code>A) Acquires Lock
  B) While Queue empty
        Wait on Condition Variable (thus suspending thread and releasing lock)
  C) Work object retrieved from queue
  D) Lock is released
  E) Do Work
  F) GOTO A
  </code></pre>
  <h3>Producer:</h3>
  <pre><code>A) Acquires Lock
  B) Work is added to queue
  C) condition variable is signaled (potentially releasing worker)
  D) Lock is released
  </code></pre>
  <p>I have been browsing some code and I saw an implementation using POSIX pipes (I have not seen this technique before).</p>
  <h3>Consumer:</h3>
  <pre><code>A) Do select on pipe (thus suspending thread while no work)
  B) Get Job from pipe
  C) Do Work
  D) GOTO A
  </code></pre>
  <h3>Producer:</h3>
  <pre><code>A) Write Job to pipe.
  </code></pre>
  <p>Since the producer and consumer are threads inside the same application (thus they share the same address space and thus pointers between them are valid); the jobs are written to the pipe as the address of the work object (A C++ object). So all that has to be written/read from the pipe is an 8-byte address.</p>
  <p>My question is:</p>
  <ul>
  <li>Is this a common technique (have I been sheltered from this) and what are the advantages/disadvantages?</li>
  </ul>
  <p>My curiosity was piqued because the pipe technique does not involve any visible lock or signals (it may be hidden in the select). So I was wondering if this would be more efficient?</p>
  <h3>Edit:</h3>
  <p>Based on comments in @Maxim Yegorushkin answer.</p>
  <p>Actually the &quot;Producer&quot; in this scenario is involved in a lot of high volume IO from lots of source in parallel. So I suspect that the original author though it very desirable that this thread did not block under any circumstances, but also did not want to high cost work in the &quot;Producer&quot; thread.</p>