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