Priority inherance issue

[Aitor Viana]

There is prob. a middle ground solution. To have less than 256 levels per
semaphore hashed (hash table)

regards,


Aitor


On Tue, May 19, 2009 at 11:37 AM, Manuel Coutinho <
manuel.coutinho at edisoft.pt> wrote:

> Hi
>
> I've already placed up for discussion, but it was thought that by
> activating
> strict order mutex would solve this.
> Just tried to test in RTEMS 4.9.2 with strict order and the result is not
> perfect.
>
> So, the issue is that when using semaphore priority inherence protocol, the
> taskA priority (task which holds the semaphore) must be equal to the
> highest
> priority of the task blocked on any of the semaphores that taskA holds.
>
> Currently, this does not happen in RTEMS.
>
> My guess to solve this issue, is that when a semaphore is released, the new
> priority of the calling thread (lets call it thread A) must be searched
> through a list (or chain) of all the threads blocked on other semaphores
> that thread A holds.
>
> Of course, also, if a thread which is blocked on semaphore is deleted, it
> has to be removed from that list.
>
> The list has some design compromises. It would be good that insertions and
> deletions took O(1), but to make this the list has to be ordered by threads
> priority. This can be done by a vector with 256 positions, just like the
> thread ready queue. But this can cause a great overhead in terms of memory
> -> each mutex needs an additional 256 * 4 bytes (1 KiB) for this list.
> I would propose that the list be composed by a chain with the chain
> handler,
> ordered by priority. This would make insertions O(n) but when a semaphore
> is
> released the priority would be quick to obtain. Deletions would also be
> O(n)
> with this solution, but it is not expected that there would be too many
> threads deletions at all during the execution of a real-time system (at
> least, hard real-time).
>
> What do you think?
> Is this an issue worth solving?
> Is my "solution" in fact a solution? If so, is it a good approach?
>
> Kind Regards
> Manuel Coutinho
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20090519/ea111f56/attachment-0001.html>