rtems_semaphore_obtain

Eric Norum norume at aps.anl.gov
Wed Mar 21 11:35:37 UTC 2007


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).

> 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?

>
>> 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.

Murphy's Law dictates that this sort of problem must appear within a  
few weeks of an official release.......
-- 
Eric Norum <norume at aps.anl.gov>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793





More information about the users mailing list