Goodbye semaphores?

Posted Jan 5, 2006 7:30 UTC (Thu) by thedevil (guest, #32913)
Parent article: Goodbye semaphores?

So what does the kernel do when a process releases a mutex? There can
be multiple other processes wanting to lock it. Are they still linked
together in a list structure? If yes, why is the mutex such a big win
over a semaphore - it seems like the same thing except that the counter
is at most 1. And if not, how does the kernel pick which process gets
its turn? It does pick a single one, right - we're not going back to
the thundering herd scenario?

Goodbye semaphores?

Posted Jan 5, 2006 7:45 UTC (Thu) by fenrus (guest, #31654) [Link]

The big win is one of complexity. With semaphores, there is the possibility of having multiple up()s in parallel, and from callers that didn't even have the semaphore. The lack of this complexity gives the mutex code more freedom to "do the right thing", far less race condition possibilities for example. (this may sound like handwaving but it's not)

Goodbye semaphores?

Posted Jan 5, 2006 9:52 UTC (Thu) by eludias (guest, #4058) [Link]

http://people.redhat.com/mingo/generic-mutex-subsystem/pa... contains:

+++ linux/Documentation/mutex-design.txt
@@ -0,0 +1,135 @@
+Generic Mutex Subsystem
+
+started by Ingo Molnar <mingo@redhat.com>
+
+ "Why on earth do we need a new mutex subsystem, and what's wrong
+ with semaphores?"

...and boils down to: smaller data (16 instead of 20 bytes/mutex), smaller code, faster (because of unknown bug in semaphore implementation), stricter semantics since a mutex in 'owned' by the locker while a semaphore shares ownership between all lockers.