On 04.04.2013 15:37, Siddhesh Poyarekar wrote:
> The generic C code was updated to use PI in current master (I don't
> remember if the arm support bits were added, but they must have been
> by now), so you could cherry-pick and backport those bits for your
> distro if you want.
Oh.. thanks for pointing out.
One more question: what exactly does lll_lock do? Is it priority
inheritance aware? It is difficult to follow all the macros
and assembler code, but as far as I can tell this ends
with calling FUTEX_WAIT.
The first thing e.g. the __pthread_cond_broadcast (and most of the
other functions as well) does is to grab lll_lock. Is the following
scenario possible?
- a low priority thread does the broadcast and gets the lock
- a medium priority thread unrelated to this condition variable
gets scheduled and preempts the low priority one right
after returning from lll_lock
- a high priority thread gets scheduled and wants to do
the broadcast on this variable too
- it finds the lock held and blocks. The medium priority thread
gets scheduled again
Now we have a classical priority inversion.
>From all that I can read it is not mandatory that the
pthread_cond_broadcast or signal is being called with the mutex
held and I think there could be more variants of this anyway.
Thanks
--
Stano
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
