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
next 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.