Under Win32, and probably other systems that support threads, there are several APIs or performing synchronisation. Each of these has a different set of costs and benefits.

For example, the process of synchronising access to a shared buffer in the above scenario might use either Mutex objects or Critical Section objects.

The former, in common with SysV Semaphores, uses named, shared, system memory to store state, as is required for inter-process signalling. Access requires a context shift into kernel space. A relatively costly process.

The latter, uses handled, process-space memory to store state. This is only usable within a single process, but is usable by all the threads of that process. Access, though managed by system API's is entirely within user space and doesn't require the context shift, and hence is faster.

Critical section objects provide synchronization similar to that provided by mutex objects, except that critical section objects can be used only by the threads of a single process. Event, mutex, and semaphore objects can also be used in a single-process application, but critical section objects provide a slightly faster, more efficient mechanism for mutual-exclusion synchronization (a processor-specific test and set instruction). Like a mutex object, a critical section object can be owned by only one thread at a time, which makes it useful for protecting a shared resource from simultaneous access.

Note. I can only view this from the perspective of Win32 & OS/2. There may well be similar facilities available in threaded unix kernels.

For the buffers involved in the read-process-write scenario, it can be possible to use an even simpler mechanism. If a circular buffer, or circular linked-list is used to buffer between the threads, then it is possible to syncronise between them using one or two pointers in process memory relying on the atomicity of integer increments and decrements where this can be replied upon, or coordinating access to these using Critical Sections. This can be cheaper still.

See Interlocking variable access & Interlocking Single-linked lists for better descriptions.