Re: "upping" a semaphore from interrupt context?

From: Satyam Sharma
Date: Sun Jun 24 2007 - 12:45:58 EST


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/