[lkml]   [2005]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/12]: MUTEX: Implement mutexes
On Sat, 17 Dec 2005, Linus Torvalds wrote:

> On Sat, 17 Dec 2005, Nicolas Pitre wrote:
> >
> > Now if you don't disable interrupts then nothing prevents an interrupt
> > handler, or another thread if kernel preemption is allowed
> Preemption, yes. Interrupts no.
> > to come
> > along right between (2) and (4) to call up() or down() which will
> > make the sem count inconsistent as soon as the interrupted down() or
> > up() is resumed.
> An interrupt can never change the value without changing it back, except
> for the old-fashioned use of "up()" as a completion (which I don't think
> we do any more - we used to do it for IO completion a looong time ago).

Maybe, but I would not bet anything on that statement. I'm sure there
are people still using semaphores for IO completion, calling up() from
interrupt handlers. And the fact is that it still works fine.

> So I think the interrupt disable could be removed for UP, at least for
> non-preemption.

This is IMHO too fragile and too easy to screw up. And it puts extra
conditions on the usage of semaphores that don't exist today.

This is why I think spliting counting semaphores and mutexes _is_ a good
thing. There is no special "no from interrupt" issue to care about with
the unlock operation, it has better performances where the count is not
important (the vast majority of all semaphores) and it produces even
smaller code (and we're all for smaller kernels, right?).

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-12-18 18:32    [W:0.072 / U:0.160 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site