Sergei Organov osv at javad.com
Thu Mar 22 15:40:39 UTC 2007

Eric Norum <norume at aps.anl.gov> writes:

> On Mar 22, 2007, at 4:23 AM, Sergei Organov wrote:
>> I'd like first to understand why RTEMS_SIMPLE_BINARY_SEMAPHORE has
>> been
>> implemented through kernel mutex in the first place. If there were no
>> sound reasons, then I'd go with switching to implementation through
>> kernel semaphore.
> Correct me if I am wrong, but I was under the impression that a
> 'classic' semaphore as described by Dijkstra (limited to values 1 and
> 0) could be used successfully  for process synchronization or for
> mutual exclusion.

Yes, indeed. However, mutexes were invented since then, and they are
supposed to be better tool for mutual exclusion. In addition, condition
variables have been invented that are more generic tool for
synchronization than semaphores (either binary or counting).

> The only difference is in the way the semaphore is initialized.  If it
> starts out 'open' its semantics are that of a mutex.

No, you get it backwards. Semaphore's semantics is still that of
semaphore. The semantics of semaphore allows to use it for mutual
exclusion, yes. When it's used for mutual exclusion, it is usually
initialized to "open" indeed. However, this initial value doesn't
magically make mutex from semaphore. Semaphore is semaphore is

> If it starts out 'closed' its semantics are those of process
> synchronization.

It's semantics is still those of semaphore. Initializing it with
"closed" value is just an indication that apparently it will be used for

> Thus I don't see anything wrong with implementing

Having semaphore semantics in the mutex implementation leads to overhead
in the mutex code. Mutex semantics allows for optimizations that can't
be performed for semaphores. For example, one idea behind mutexes was
that they could be specifically optimized for the case of rare
contention. Another example is that current mutex code contains IRQ
disable/enable code that probably could be avoided once we remove
semaphore semantics from mutex code.

On the other hand, mutexes usually have more heavy slow pass invoked in
the case of contention, and as synchronization usually invokes this
pass, it's inefficient to use mutex code for synchronization purposes.

> Can you show in the RTEMS implementation of
> RTEMS_SIMPLE_BINARY_SEMAPHORE where the problem with releasing from an
> ISR occurs?

No. I don't care. I don't use mutexes from ISRs anyway.

> If so we should either fix what is broken or as you suggested change
> the RTEMS_SIMPLE_BINARY_SEMAPHORE implementation to use a core
> semaphore.

I didn't suggest that. I just mentioned that I've added RTEMS_BSEMAPHORE
support for my own purposes, and are willing to share it with the
community if the community is interested.

> If there's no identifiable problem with the existing implementation I
> see no need to make any changes.

That's still the question. OP had a problem when using
RTEMS_SIMPLE_BINARY_SEMAPHORE. It's still not clear if this is problem
with OP's code, or RTEMS mutex kernel code when invoked from ISR. My
point was that if RTEMS_SIMPLE_BINARY_SEMAPHORE was implemented as
semaphore, this question didn't arise in the first place.


More information about the users mailing list