rtems_semaphore_obtain

[Sergei Organov]

Eric Norum <norume at aps.anl.gov> writes:
> On Mar 20, 2007, at 2:39 PM, Chris Xenophontos wrote:
>
>> The first change I've made is to create a Counting Semaphore, i.e,
>> changed
>> the attributes of the semaphore in question from:
>>
>> ( RTEMS_FIFO |
>>   RTEMS_NO_INHERIT_PRIORITY |
>>   RTEMS_SIMPLE_BINARY_SEMAPHORE |
>>   RTEMS_NO_PRIORITY_CEILING |
>>   RTEMS_LOCAL ),
>>
>> to:
>>
>> ( RTEMS_FIFO |
>>   RTEMS_NO_INHERIT_PRIORITY |
>>   RTEMS_COUNTING_SEMAPHORE  |
>>   RTEMS_NO_PRIORITY_CEILING |
>>   RTEMS_LOCAL ),
>>
>> I have to let it run like this another 18 hours to see if there is any
>> change.
>>
>> If I understand your comments, Binary Semaphores should not be
>> called from
>> ISRs?
>
> Sergei -- Are you perhaps confusing Binary Semaphores with Simple
> Binary Semaphores?

Well, somewhat. Maybe I didn't express my point clear enough (even to
myself). RTEMS_BINARY_SEMAPHORE is supposed to be mutex and can't be
used from ISRs, -- no questions.  RTEMS_SIMPLE_BINARY_SEMAPHORE is
supposed to be just binary semaphore, but it maps to the same kernel
mutex code that might not work correctly in the case of releasing from
ISR.

Long time ago I've introduced my own RTEMS_BSEMAPHORE flag and mapped it
to the kernel semaphore with limited counter (there is ready-to-use
support for limited counters in vanilla RTEMS kernel), and as I use it
(as well as RTEMS_COUNTING_SEMAPHORE) from ISRs quite heavily, I'm sure
the kernel semaphore has no problems with releasing from ISRs. I'm not
sure about RTEMS_SIMPLE_BINARY_SEMAPHORE as it maps to different (mutex)
code in the kernel, that I consider to be a design flaw in the first
place.

> Simple binary semaphores do not have the "unlock only by locking
> thread" restriction -- if they did then Chris's program would never
> work at all.

Yes, I see.

> I don't see why it should be illegal to release a simple binary
> semaphore from an interrupt handler.

It should not be illegal. But the fact that it maps to kernel mutex
makes me think that there could be some bug there, as usually mutex is
not supposed to work from ISR.

> BTW -- I usually use events to unblock tasks waiting for interrupts.

Yes they are useful, but it could be a problem if you don't know which
task(s) could be awaiting for interrupt, as you need to specify
destination task when sending event(s).

There are situations when message queues are also inappropriate.

Overall, message queues, events, and counting semaphores should work
just fine from ISR context as so many people do use them that way. I'm
not sure RTEMS_SIMPLE_BINARY_SEMAPHORE code is that thoroughly tested
for the case of unlocking from ISR context (or even is expected to work
from ISR context at all).

-- 
Sergei.