All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stanislav Meduna <stano@meduna.org>
To: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com>
Cc: libc-help <libc-help@sourceware.org>,
	"linux-rt-users@vger.kernel.org" <linux-rt-users@vger.kernel.org>
Subject: Re: malloc/free and priority inheritance?
Date: Thu, 04 Apr 2013 17:09:44 +0200	[thread overview]
Message-ID: <515D97B8.5030101@meduna.org> (raw)
In-Reply-To: <CAAHN_R1zLdHqpC4JGxjJtADRWGA0hC=G2C3=0Z21KTKk5HJNtg@mail.gmail.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


  parent reply	other threads:[~2013-04-04 15:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-02 23:06 malloc/free and priority inheritance? Stanislav Meduna
2013-04-04 12:59 ` Stanislav Meduna
2013-04-04 13:30   ` Stanislav Meduna
2013-04-04 13:37     ` Siddhesh Poyarekar
2013-04-04 14:53       ` Carlos O'Donell
2013-04-04 15:32         ` Siddhesh Poyarekar
2013-04-06 14:24           ` Carlos O'Donell
2013-04-04 15:09       ` Stanislav Meduna [this message]
2013-04-04 15:39         ` Siddhesh Poyarekar
2013-04-05 17:39           ` Darren Hart
2013-04-06 14:27             ` Carlos O'Donell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=515D97B8.5030101@meduna.org \
    --to=stano@meduna.org \
    --cc=libc-help@sourceware.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=siddhesh.poyarekar@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.