sem issues part 500

[Philippe Gerum]

Steven Seeger wrote:
> Hi Philippe. I am not familiar with this concept. Care to explain a little
> bit?

There is a detailed explanation of this (and more) in this old article 
still available on-line (it's a long one discussing other matters, you 
may want to search for "priority inheritance"):
http://www.embedded.com/2000/0006/0006feat1.htm

> 
> BTW, I am having great success with your last couple of adeos patches, even
> in the realm of printks. You probably guessed this due to my lack of
> complaints. :)
>

Thanks, reading good news from times to times is encouraging, because I 
must admit that adapting Adeos to the recent kernel 2.6 releases for x86 
has been the nearest thing to a PITA, among the various braindamage 
activities I can think of right now...

> Steven
> 
> 
> On 6/2/05 12:14 AM, "Philippe Gerum" <rpm at xenomai.org> wrote:
> 
> 
>>Steven Seeger wrote:
>>
>><snip>
>>
>>>        This is not how a PIP, as you call it, should work. The
>>>        priorities should ³unwind² as resources are released. Each task
>>>        will have to have a way of easily knowing what semaphores it
>>>        owns (like semaphores know what tasks own them) and then when
>>>        rt_sem_signal is called, that task¹s priority adjusted accordingly.
>>>
>>
>>If the priority of your task never changes, maybe that what you need
>>actually is priority ceiling, so that it can hold multiple resources
>>concurently without risking deadlocks.
> 
> 
> 
> _______________________________________________
> RTAI mailing list
> RTAI at rtai.org
> https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai


-- 

Philippe.