rtems_semaphore_obtain

[Sergei Organov]

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

> On Mar 23, 2007, at 9:14 AM, Sergei Organov wrote:
>
>
>>
>> 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.
>
> Perhaps I misunderstand this statement.

Yes.

>
> The semantics of a strict priority scheduler require that unlocking a
> mutex perform a check to see whether a higher priority task is
> blocked waiting for that mutex -- if so a task switch is required.
> Does your statement imply some either kind of operation?

When you call, say, rtems_semaphore_obtain(), this routine should first
decide, based on current semaphore flags, what particular internal
routine to call, either kernel_semaphore_obtain(), or
kernel_mutex_obtain() (actual RTEMS function names are
different). However, it's actually known at compile-time if program
needs mutex or semaphore, so this dispatch could be eliminated entirely,
provided distinct API routines are to be called for mutexes and
semaphores.

-- Sergei.