This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: malloc/free and priority inheritance?
- From: Stanislav Meduna <stano at meduna dot org>
- To: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>
- Cc: libc-help <libc-help at sourceware dot org>, "linux-rt-users at vger dot kernel dot org" <linux-rt-users at vger dot kernel dot org>
- Date: Thu, 04 Apr 2013 17:09:44 +0200
- Subject: Re: malloc/free and priority inheritance?
- References: <515B647C dot 3080505 at meduna dot org> <515D7943 dot 5000401 at meduna dot org> <515D808C dot 8090808 at meduna dot org> <CAAHN_R1zLdHqpC4JGxjJtADRWGA0hC=G2C3=0Z21KTKk5HJNtg at mail dot gmail dot com>
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