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. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
