All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Singleton <dsingleton@mvista.com>
To: robustmutexes@lists.osdl.org
Cc: Ingo Molnar <mingo@elte.hu>, linux-kernel@vger.kernel.org
Subject: Robust Futex patches available
Date: Tue, 22 Nov 2005 12:38:44 -0800	[thread overview]
Message-ID: <438381D4.5020904@mvista.com> (raw)


    There are two new patches for Robust Futex support available at

    http://source.mvista.com/~dsingleton

    patch-2.6.14-rt13-rf3 fixes two locking bugs which caused hangs and 
deadlocks.

    patch-2.6.14-rt13-rf4 adds support for pthread_mutexes 'malloc'ed on 
the heap.

    I'd also like some advice on the direction POSIX is heading with 
respect to
    robust pthread_mutexes and priority inheritance.

    It appears there are some not used openposix tests that use 
different flags for
    defining robustness.      Here is a snip from the openposix robust 
test's README:

Robust Mutex Tests
------------------------
The tests are under <rtnptl-tests>/robust_test directory.

rt-nptl supports 'robust' behavior, there will be two robust modes,
one is PTHREAD_MUTEX_ROBUST_NP mode, the other is
PTHREAD_MUTEX_ROBUST_SUN_NP mode. When the owner of a mutex dies in
the first mode, the waiter will set the mutex to ENOTRECOVERABLE
state, while in the second mode, the waiter needs to call
pthread_mutex_setconsistency_np to change the state manually.

Currently the PTHREAD_MUTEX_ROBUST_NP is providing
the fucntionality described by the PTHREAD_MUTEX_ROBUST_SUN_NP.

Any advice on which way we should go?   I feel we should follow
POSIX and provide both methods and the new pthread_mutex_setconsistency_np
function which provides the mutex recovery mechanism.

David


             reply	other threads:[~2005-11-22 20:38 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-22 20:38 David Singleton [this message]
     [not found] ` <a36005b50511221740i6a80d59ay3983067e756cb5f6@mail.gmail.com>
2005-11-24  0:43   ` Robust Futex patches available david singleton

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=438381D4.5020904@mvista.com \
    --to=dsingleton@mvista.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=robustmutexes@lists.osdl.org \
    /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.