I believe mutex is a primitive construct, hardware-wise, therefore elemental and low-level. It’s NOT built using condition variables or counting semaphores. In contrast,
– mutex is usually needed _inside_ counting Semaphore. See OS/2 and java. Also see solaris pthreads sem_wait() and sem_post() [1] as described on P93 [[Bil Lewis]]
– mutex is usually needed as guard _around_ Condition var. See java, pthreads [[Bil Lewis]] and boost thread.
** In fact, both work similarly. See similarity between the wait-loops in [[Bill Lewis]].
Complicating the big 3 interdependency, when one of several “grabbing” threads is given the contended mutex, system may internally send signals, but that happens at a lower level than a condition var. Condition variable and Counting semaphore probably depends on the same low-level signaling. This low-level signaling construct is not an API construct and not one of our big 3.
counting semaphore is less fundamental than mutex and condition variables.
* java has built-in support for M and C but not S
* OS/2 doesn’t support counting semaphore. Note For some time, pthreads, win32 and OS/2 are the 3 dominant thread implementation,
[1] pthreads sem_wait() means “grab a permit”, sem_post() means “return my permit to the pool”.
— Jargon clean-up —
There are 2 distinct meanings of “semaphore”+ some vague meanings.
1) Counting semaphore is the first and best known semaphore API.
2) Other types of semaphores were added, notably System V IPC semaphores.
x) In some discussions, “semaphores” vaguely mean “various synchronization variables” and includes mutex, condVar and countingSemaphores.
The counting semaphore concept is fundamental and elemental, but implementation-wise, it’s always constructed using mutex and condVar.
Some people chose to write their own counting semaphore using mutex, condVar and a counter
Q: why is “lock” not in our big 3.
A: “Lock” often means mutex, but is sometimes a wrapper on a mutex, as in boost.
— sysV semaphore and shared memory
Linux supports three types of IPC mechanisms — message queues, sysV IPC semaphores and shared memory. As the Camel book points out, those are the same 3 sysV IPC constructs.
Once the memory is shared, there are no checks on how the processes are using it. They must rely on other mechanisms, for example System V semaphores, to synchronize access to shared memory.