Weekly Edition
Return to the Kernel page
| |||||||||||||
Goodbye semaphores?
In the previous episode, Ingo
Molnar had posted his own version of the mutex patch, adding a new
synchronization primitive to the kernel. Ingo has continued to refine this
patch set, with frequent releases; the current version is
Perhaps the most significant development since then has been a private conversation between Andrew and Ingo. There is, it seems, a plan in place which would replace the current semaphore implementation entirely. Almost all current semaphore users are implementing simple mutual exclusion areas, so they would be converted over to the new mutex type directly. An estimated 90% of current semaphore users fall into this category. Of the remaining users, about 90% employ semaphores to indicate event completion. The task of converting those users to the completion type has been ongoing for some time; replacing semaphores would require finishing this job. Finally, an estimated 1% of the semaphores in the kernel are used for their counting feature; they can be converted over to a (not yet posted) architecture-independent counter type. Once all that work is done, semaphores could be removed from the kernel altogether. Says Andrew: "It's a lot of churn, but we'll end up with a better end result and a somewhat-net-simpler kernel, so I'm happy." Linus, meanwhile, has offered some suggestions for improvements (already incorporated by Ingo) and stated: "At that point I'd like to switch to mutexes just because the code is cleaner!" Since then, most of the discussion has been concerned with the details of the mutex implementation rather than whether it is fundamentally a good idea or not. The main objections would appear to have been overcome. So, unless something new comes up, it looks like this change is going to happen; the only question is "when." The next couple of weeks will determine whether the mutex code will be part of 2.6.16 or not. Then all that's left is the long task of converting all semaphore users over and, finally, removing the old semaphore code. (Log in to post comments)
Goodbye semaphores? Posted Jan 5, 2006 6:02 UTC (Thu) by NightMonkey (subscriber, #23051) [Link] Can some kind soul post a link to a decent explicative discussion of what semaphores and mutexes are, in the context of the kernel, and how the kernel makes use of them? Thanks in advance.
Goodbye semaphores? Posted Jan 5, 2006 7:48 UTC (Thu) by fenrus (guest, #31654) [Link] To a large degree a mutex is sort of a sleeping spinlock. Eg it provides exclusion against other users of the lock, and the code pattern is "get lock; do stuff; release lock". (where "get lock" may sleep, unlike spinlocks).
Semaphores have a counter. They can be used in a mutexy way, but they can also be used for their counting property. Say you have 4 resources of something (say a piece of hardware). You start the counter at 4, and each kernel piece that uses the hardware first decrements (down) the count, and it increments (up) it back when it's done with the hardware. Semaphores sleep when the counter hits negative in down(), and the incremener up() wakes processes back up to be able to use the recently freed resource now.
By default, the counter is 1, and there is mutex-like behavior, but this is just a default and optional.
Goodbye semaphores? Posted Jan 5, 2006 7:30 UTC (Thu) by thedevil (subscriber, #32913) [Link] So what does the kernel do when a process releases a mutex? There canbe 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 (subscriber, #4058) [Link] http://people.redhat.com/mingo/generic-mutex-subsystem/pa... contains:
+++ linux/Documentation/mutex-design.txt
...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.
Goodbye semaphores? Posted Jan 6, 2006 3:22 UTC (Fri) by stock (guest, #5849) [Link] What about old source code which needs semaphores? What about oldbinaries which need semaphores? Do we really want to see linux become a eccentric vehicle like plan9 or the GNU mach kernel? Robert
Goodbye semaphores? Posted Jan 6, 2006 3:26 UTC (Fri) by busterb (subscriber, #560) [Link] These are semaphores inside the kernel; userspace can still usesemaphores.
Goodbye semaphores? Posted Jan 7, 2006 14:40 UTC (Sat) by jospoortvliet (subscriber, #33164) [Link] the old sourcecode needs to be fixed, and well - we all know to whatextend the kernel supports binary code... :D
Goodbye semaphores? Posted Jan 9, 2006 2:27 UTC (Mon) by stock (guest, #5849) [Link] linux-abi is still used by me.
Goodbye semaphores? Posted Jan 9, 2006 18:51 UTC (Mon) by MenTaLguY (guest, #21879) [Link] If you're thinking of POSIX semaphores, those are something different; this change is part of the internal kernel APIs, not the userspace ABI...
|
|||||||||||||