Re: "upping" a semaphore from interrupt context?

[Satyam Sharma]

On 6/23/07, Robert P. J. Day <rpjday@xxxxxxxxxxxxxx> wrote:
> On Sat, 23 Jun 2007, Satyam Sharma wrote:
>
> > Hi Robert, Arnd,
> >
> > On 6/23/07, Arnd Bergmann <arnd@xxxxxxxx> wrote:
> > > On Saturday 23 June 2007, Robert P. J. Day wrote:
> > > > On Fri, 22 Jun 2007, Arnd Bergmann wrote:
> > > > >
> > > > > yes, but you should not. The use of semaphores is not recommended
> > > > > for new code, it should be replaced with either a mutex or a
> > > > > completion.
> > > >
> > > > can you clarify this? it sounds like you're saying that the current
> > > > implementation of semaphores is entirely superfluous. but surely it
> > > > isn't possible to replace all semaphores with either mutexes or
> > > > completions, is it?
> >
> > Semaphores being used as completions are superfluous, obsoleted by
> > completion handlers. Semaphores that are not counted (hence binary)
> > are superfluous, obsoleted by struct mutex.
>
> hang on, how is that true?  as i read it, mutexes are more than just
> binary semaphores -- they have additional restrictions that regular
> semaphores don't.

Yes, they do have additional restrictions (mutex_trylock() illegal from
contexts that cannot sleep, mutexes may only be unlocked by tasks
that took them in the first place). But note that these are
_implementation_ sanity checks that were introduced to catch
nonsensical usage, which was possible (and not explicitly being
guarded against, because of the generic-ness that was needed to
be maintained for the counted case too) with the "semaphore"s.

> so i'm not convinced that binary semaphores can
> simply be replaced by mutexes, unless that's not what you meant here.

I do mean precisely that. I really cannot think of any sensible / normal
usage case of binary semaphores that cannot be replaced with either
mutexes (if that's the kind of locking you actually want) or completion
handlers (if that's the kind of synchronization you actually want).

Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/