rtems_semaphore_obtain

[Pavel Pisa]

On Thursday 22 March 2007 16:40, Sergei Organov wrote:
> > Thus I don't see anything wrong with implementing
> > RTEMS_SIMPLE_BINARY_SEMAPHORE with a core mutex.
>
> 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.

Hello All,

I would like to affirm to more clear mutex semantics.

I have already though about the problem of the RTEMS
semaphore some time ago and I would vote to have new
executive directives

  rtems_mutex_obtain
  rtems_mutex_release
  rtems_mutex_create
  ...

They could be aliases to actual semaphore ones with
preset flags for create for now

  rtems_semaphore_obtain
  rtems_semaphore_release
  rtems_semaphore_create
  ...

They should use different object class in the long term run to catch
mismatch between different uses in the application code.

I do not see the implementation optimizations as critical reason for that,
but the ability to check and read own or others code. When mutex obtain
directive is called, there has to bee matching release in the same function
or function documentation has to specify, that caller has to take
care for release. These things can be even check by tools like Linus's
sparse. Linux kernel has converted use of semaphores as mutexes to
explicit mutex primitives calls last year for this reason and ability
to add priority inheritance.

The actual state does not allow to simply check incorrect obtain/release
pairs matching, because it is complex to match actual mutex use to semaphore 
initialization, which is only place to check, that object is really mutex.

In the long run, the actual mutex and semaphore implementations could
be more separated and optimized.

Best wishes

             Pavel Pisa