Re: [Xenomai-help] Scheduler: Strange priority handling

[Philippe Gerum <rpm@xenomai.org>]

On Mon, 2007-05-14 at 13:57 +0200, M. Koehrer wrote:
> HI all,
> 
> thanks for all the responses.
> Using mutexes instead of semaphores actually solves the issue.
> However, the API documentation of rt_sem_create() is a little bit confusing here.
> The "mode" parameter of rt_sem_create() may contain "S_PRIO" which 
> "makes tasks pend in priority order on the semaphore".
> I interpret this that it works actually the very same as with mutexes. 

No, absolutely not. Please reread the detailed explanations. This is
_not_ a matter of priority management wrt sema4, but the ability for the
nucleus to steal the resource depending on the respective priority of
_threads_ that want to consume it. S_PRIO is about setting the sema4
behaviour when it comes to enqueue pending threads for _sleeping_ on a
resource; this has nothing to do with how a running thread might steal a
sema4 resource from another one due to its priority being higher
combined to the fact that the current owner of the resource did not wake
up yet in the meantime.

> However, it
> is implemented that sem_v directly triggers a waiting task (even if it is low prio).
> As the semaphore has nothing to do with the scheduler, this makes sense.
> However, this cannot be found within the API documentation.

The sema4 does have something to do with the scheduler: it calls its
services to operate on the thread runstates. But there is nothing else
to document, aside of "semaphores do work as expected", in this case.

> 
> Regards
> 
> Mathias
> 
-- 
Philippe.