Re: "upping" a semaphore from interrupt context?

[Satyam Sharma]

Hi Robert,

On 6/24/07, Robert P. J. Day <rpjday@xxxxxxxxxxxxxx> wrote:
> On Sat, 23 Jun 2007, Satyam Sharma wrote:
>
> > On 6/23/07, Robert P. J. Day <rpjday@xxxxxxxxxxxxxx> wrote:
>
> > > 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).
>
> ok, i can see what you're getting at now.  i'm just going to have to
> convince myself that, once you have mutexes and completions, you have
> no further need for even general counting semaphores.

Whoa, hold on. But I've been explicitly mentioning *binary* semaphores
all along!

Of course users who want / allow multiple tasks (but only upto a specific
maximum number, which is what counted semaphores are all about)
to be present in a given critical section simultaneously would still want
to use the _counted_ semaphores, which is why you won't see the old
"struct semaphores" dying anytime soon.

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/