rtems_semaphore_obtain

[Sergei Organov]

Eric Norum <norume at aps.anl.gov> writes:
> On Mar 21, 2007, at 5:03 AM, Sergei Organov wrote:
>
>>
>> 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.
>>
>
> That is very important.
> I was not aware of that.
> I would classify that as a bug.  It certainly violates the "principle
> of least surprise" since I was under the impression that other RTEMS
> directives which can not block are safe to call from an interrupt
> handler (e.g. event send, message send).

Did you miss 'might' in my sentence? It is just my guess that it could
be a bug there, -- I didn't actually check the code.

>> 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.
>
> It sounds like your implementation of "simple binary semaphores"  is
> superior to the one now in RTEMS.  Would it be possible for your
> implementation to be folded into the distribution -- and a great big
> warning added to the RTEMS-.47 known problems list and to the
> RTEMS-4.7 semaphore documentation?

I don't say it's know problem. I just guessed that there *might* be some
problem there. If the OP finds that counting semaphore or, better,
event, works for him, then chances will be higher that the problem is in
the RTEMS mutex code, and not in the OP's application.

As for changing current semantics of RTEMS_SIMPLE_BINARY_SEMAPHORE, I'm
afraid some existing code might be affected, and adding yet another
different kind of "semaphore" may add to already existing confusion.

Anyway, if decision will be to add true binary semaphores support to the
RTEMS API, I'll be happy to provide a patch. [Note that RTEMS kernel
does have the support].

-- 
Sergei.