rtems_semaphore_obtain

[Sergei Organov]

Daron Chabot <daron.chabot at usask.ca> writes:

[...]

>> > status = rtems_semaphore_create( "MISR",  0, 
>> > ( RTEMS_FIFO | RTEMS_NO_INHERIT_PRIORITY | RTEMS_SIMPLE_BINARY_SEMAPHORE |
>> 
>> The binary semaphore could be a problem here. AFAIR, binary semaphore
>> maps to a core mutex(!) in RTEMS[1], and using a mutex from ISR context
>> could lead to problems[2]. I'd try to substitute counting semaphore or
>> event for binary semaphore and see what happens.
>> 
>> [1] I think this is a design flaw. Binary semaphore must map to the core
>>     semaphore with counter limited by 1.
>> 
>> [2] Mutexes are usually more restricted than semaphores. Only the thread
>>     that locked the mutex may unlock it, so mutexes are to be used only
>>     for mutual exclusion, not for synchronization. IMHO all the
>>     operations on mutexes (called binary semaphore in RTEMS) from ISR
>>     context should be explicitly prohibited.
>
> As already covered in previous posts, [2] is not absolutely correct.

There is probably nothing in this world that is absolutely correct ;)

> From my understanding of cpukit/rtems/src/semcreate.c, semaphores
> (mutexes) created with the priority_ceiling or priority_inherit
> disciplines share the restriction that only the semaphore's "owner" may
> release them.

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.

> So... since ISRs do not have an "identity", mutexes employing those
> disciplines *cannot* be used from an ISR (i.e. release( )'d). However, I
> haven't yet verified that this behavior is indeed what is actually
> implemented.

My point is that mutex shouldn't be used from ISR context no matter how
it is implemented in the first place, because there is simply no sense
in using mutex from ISR.

-- 
Sergei.