osv at javad.com
Fri Mar 23 16:27:10 UTC 2007
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.
> 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
More information about the users