* Roman Zippel <[email protected]> wrote:
> > c) semaphores are total overkill for 99% percent of the users. Remember
> > this thing about optimizing for the common case?
>
> [...] I also haven't hardly seen any discussion about why semaphores
> the way they are. Linus did suspect there is a wakeup bug in the
> semaphore, but there was no conclusive followup to that.
no conclusive follow-up because ... they are too complex for people to
answer such questions off the cuff? Something so frequently used in
trivial ways should have the complexity of that typical use, not the
complexity of the theoretical use. There is no problem with semaphores,
other than that they are not being used as semaphores all that often.
for which i think there is a rather simple practical reason: if i want
to control a counted resource within the kernel, it is rarely the
simplest solution to use a semaphore for it, because a semaphore cannot
be used to protect data structures in the 'resource is available' stage
[i.e. when the semaphore count is above zero]. It does decrement the
counter atomically, but that is just half of the job i have to do.
to control (allocate/free) the resource i _have to_ add some other
locking mechanism anyway in most cases (a spinlock most likely, to
protect the internal list and other internal state) - at which point
it's simpler and faster to simply add a counter and a waitqueue to those
existing internal variables, than to add a separate locking object to
around (or within) the whole construct.
semaphores would be nice in theory, if there was a way to attach the
'decrement counter atomically' operation to another set of atomic ops,
like list_del() or list_add(), making the whole thing transactional.
[this would also be a wholly new API, so it only applies to semaphores
as a concept, not our actual semaphore incarnation] So i see the
theoretical beauty of semaphores, but in practice, CPUs force us to work
with much simpler constructs.
there are some exceptions: e.g. when the resource is _nothing else_ but
a count.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
