rtems_semaphore_obtain

[Sergei Organov]

Daron Chabot <djc915 at mail.usask.ca> writes:
> On 22-Mar-07, at 7:07 AM, Sergei Organov wrote:
> > Daron Chabot <daron.chabot at usask.ca> writes:
[...]
> > Let's separate general term "mutex" from its implementation in RTEMS
> > for a moment. "Mutex" in general is a restricted kind of binary
> > semaphore specifically designed for the purpose of using it for
> > MUTual EXclusion, where restriction is that only owner of the mutex
> > may unlock it.  It's this restriction that allows to implement
> > priority ceiling, inheritance, nesting, and some optimizations for a
> > mutex. Therefore, skipping priority ceiling or inheritance from a
> > mutex implementation doesn't magically turn mutex into binary
> > semaphore.
> >
> > Now, it could be the case that RTEMS implementation of a mutex makes
> > it safe to [ab]use it for synchronization (as opposed to mutual
> > exclusion), and maybe even from ISR context, when no priority ceiling
> > or inheritance is configured for this mutex, but I'd avoid such abuse
> > anyway.
> >
> > In fact I'm re-reading the RTEMS semaphore initialization code, and
> > it seems that provided no priority ceiling/inheritance is in use,
> > RTEMS_BINARY_SEMAPHORE and RTEMS_SIMPLE_BINARY_SEMAPHORE only differ
> > in their nesting behavior (SIMPLE one blocks on nesting, while usual
> > one acquires on nesting), so it indeed seems that for whatever reason
> > RTEMS tries to magically turn a mutex into a binary semaphore using
> > RTEMS_SIMPLE_BINARY_SEMAPHORE magic, as explicit blocking on nesting
> > makes no sense for a mutex.
> >
> > Overall, it seems that RTEMS_BINARY_SEMAPHORE should be read "mutex",
> > and RTEMS_SIMPLE_BINARY_SEMAPHORE should be read "binary semaphore"
> > (though implemented as a kind of mutex that is both strange and
> > illogical). IMHO RTEMS got it wrong in the first place, that leads to
> > lack of clear separation between different concepts, to confusion, and
> > to too heavy mutex implementation.
>
> I agree that at least some of the problem can be attributed to having
> 3 types of semaphore in RTEMS (BINARY, SIMPLE_BINARY, and COUNTING).

>From which only COUNTING is a true semaphore, all others being in fact
mutexes, though SIMPLE_BINARY may be attributed as binary semaphore
indeed, though again implemented as kind of mutex.

> It would make sense to me to have only two types:
> 1) RTEMS_MUTEX
>     -- used solely for mutual exclusion purposes
>     -- limited (by definition) to the values, 0 and 1
>     -- has the attributes NESTING_ACQUIRES and onlyOwnerRelease==TRUE
>     -- follows either the PRIORITY_CEILING or PRIORITY_INHERIT
>        disciplines

Yes, except NESTING_IS_ERROR could also be useful, as well as
DISCIPLINES_PRIORITY and DISCIPLINES_FIFO.

>
> 2) RTEMS_SEMAPHORE
>     -- used for synchronization and resource-pool protection
>     -- may take any positive value (1,2,3,...,N)

any non-negative value, in fact.

>     -- has the attributes NESTING_BLOCKS and onlyOwnerRelease==FALSE

Strictly speaking, there is no sense to even talk about "nesting" and
"owner" in the context of semaphores, -- they just don't have such
attributes. However, if we consider this to be general characteristics
of semantics, then yes, any thread can release semaphore and it does
block the thread acquiring it twice.

I'd add binary semaphore to the picture anyway:

 3) RTEMS_BINARY_SEMAPHORE
    -- used for synchronization
    -- may take only (0,1) values

They are sometimes useful for synchronization indeed. But now, there is
a problem of backward compatibility that should be solved that way or
another. In particular, it's not that good idea to silently change
RTEMS_BINARY_SEMAPHORE semantics from mutex to binary semaphore, though
we can make RTEMS_MUTEX to be a synonym for RTEMS_BINARY_SEMAPHORE, and
re-implement RTEMS_SIMPLE_BINARY_SEMAPHORE as true semaphore.

Alternatively, the RTEMS kernel idea of the semaphore having
configurable upper limit of its internal counter could be reflected in
the interface, -- then binary semaphore will become just a case of
generic counting semaphore with upper limit == 1.

BTW, getting rid of semaphore behavior from mutex will allow to get rid
of IRQ disable/enable code in the mutex implementation, I think.

-- Sergei.