There is prob. a middle ground solution. To have less than 256 levels per semaphore hashed (hash table)<br><br>regards,<br><br clear="all"><br>Aitor<br>
<br><br><div class="gmail_quote">On Tue, May 19, 2009 at 11:37 AM, Manuel Coutinho <span dir="ltr"><<a href="mailto:manuel.coutinho@edisoft.pt">manuel.coutinho@edisoft.pt</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi<br>
<br>
I've already placed up for discussion, but it was thought that by activating<br>
strict order mutex would solve this.<br>
Just tried to test in RTEMS 4.9.2 with strict order and the result is not<br>
perfect.<br>
<br>
So, the issue is that when using semaphore priority inherence protocol, the<br>
taskA priority (task which holds the semaphore) must be equal to the highest<br>
priority of the task blocked on any of the semaphores that taskA holds.<br>
<br>
Currently, this does not happen in RTEMS.<br>
<br>
My guess to solve this issue, is that when a semaphore is released, the new<br>
priority of the calling thread (lets call it thread A) must be searched<br>
through a list (or chain) of all the threads blocked on other semaphores<br>
that thread A holds.<br>
<br>
Of course, also, if a thread which is blocked on semaphore is deleted, it<br>
has to be removed from that list.<br>
<br>
The list has some design compromises. It would be good that insertions and<br>
deletions took O(1), but to make this the list has to be ordered by threads<br>
priority. This can be done by a vector with 256 positions, just like the<br>
thread ready queue. But this can cause a great overhead in terms of memory<br>
-> each mutex needs an additional 256 * 4 bytes (1 KiB) for this list.<br>
I would propose that the list be composed by a chain with the chain handler,<br>
ordered by priority. This would make insertions O(n) but when a semaphore is<br>
released the priority would be quick to obtain. Deletions would also be O(n)<br>
with this solution, but it is not expected that there would be too many<br>
threads deletions at all during the execution of a real-time system (at<br>
least, hard real-time).<br>
<br>
What do you think?<br>
Is this an issue worth solving?<br>
Is my "solution" in fact a solution? If so, is it a good approach?<br>
<br>
Kind Regards<br>
Manuel Coutinho<br>
<br>
_______________________________________________<br>
rtems-users mailing list<br>
<a href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a><br>
<a href="http://www.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-users</a><br>
</blockquote></div><br>