rtems_semaphore_obtain

[Sergei Organov]

Pavel Pisa <ppisa4lists at pikron.com> writes:
> 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

I'm +1 on this, except that for mutexes, "lock" and "unlock" names are
more widely recognized for "obtain" and "release", I believe.

[...]

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

Besides, it will allow to get rid of current run-time dispatch of every
operation on either mutex or semaphore between kernel mutex and
semaphore code, respectively.

[...]

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

The irony is that they already are rather separate in the RTEMS
*kernel*, though are indeed mixed in the RTEMS API.

Then, for whatever reason, binary semaphore is implemented as kernel
mutex, mixing in semaphore semantics into otherwise clearly "mutex"
internal RTEMS kernel code, and this thing could be fixed without
changes in the API.

-- Sergei.