From: Jan Kiszka <jan.kiszka@domain.hid>
To: gilles.chanteperdrix@xenomai.org
Cc: xenomai-core <xenomai@xenomai.org>
Subject: Re: [Xenomai-core] [RFC][PATCH 2/3] Switch to handle-based fast mutex owners
Date: Wed, 27 Aug 2008 16:38:36 +0200 [thread overview]
Message-ID: <48B566EC.1020804@domain.hid> (raw)
In-Reply-To: <48B5615C.6050704@domain.hid>
Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> To improve robustness of the fast mutex implementation in POSIX (and
>> later on in native), it is better to track the mutex owner by handle
>> instead of kernel object pointer. Therefore, this patch changes
>> __xn_sys_current (xeno_set_current) so that it returns
>> xnthread_handle(current_thread). It furthermore converts the POSIX mutex
>> implementation to pick up and store the lock owner as handle in the
>> kernel/user-shared mutex. Finally it ensures that at least POSIX threads
>> always have an (anonymous) handle assigned.
>>
>> As the value stored in the mutex variable is now an integer, we can
>> switch over to xnarch_atomic_t, removing all atomic_intptr users.
>
> Ok. I do not know if this should be part of this patch, or in another
> one, but we should call xeno_set_current in the trampolines of all
> skins, so that they can use the native and posix mutexes.
>
> This is another thing that I have left in a state of flux...
Find it below (PATCH 4/3).
BTW, should we better invoke pthread_exit in xeno_set_current in case of
a failure?
Jan
---
src/skins/native/task.c | 3 +++
src/skins/psos+/task.c | 3 +++
src/skins/uitron/task.c | 3 +++
src/skins/vrtx/task.c | 3 +++
src/skins/vxworks/taskLib.c | 3 +++
5 files changed, 15 insertions(+)
Index: b/src/skins/native/task.c
===================================================================
--- a/src/skins/native/task.c
+++ b/src/skins/native/task.c
@@ -26,6 +26,7 @@
#include <limits.h>
#include <native/syscall.h>
#include <native/task.h>
+#include <asm-generic/bits/current.h>
#include "wrappers.h"
extern pthread_key_t __native_tskey;
@@ -88,6 +89,8 @@ static void *rt_task_trampoline(void *co
if (err)
goto fail;
+ xeno_set_current();
+
/* Wait on the barrier for the task to be started. The barrier
could be released in order to process Linux signals while the
Xenomai shadow is still dormant; in such a case, resume wait. */
Index: b/src/skins/psos+/task.c
===================================================================
--- a/src/skins/psos+/task.c
+++ b/src/skins/psos+/task.c
@@ -26,6 +26,7 @@
#include <memory.h>
#include <string.h>
#include <psos+/psos.h>
+#include <asm-generic/bits/current.h>
extern int __psos_muxid;
@@ -89,6 +90,8 @@ static void *psos_task_trampoline(void *
if (err)
goto fail;
+ xeno_set_current();
+
/* Wait on the barrier for the task to be started. The barrier
could be released in order to process Linux signals while the
Xenomai shadow is still dormant; in such a case, resume wait. */
Index: b/src/skins/uitron/task.c
===================================================================
--- a/src/skins/uitron/task.c
+++ b/src/skins/uitron/task.c
@@ -25,6 +25,7 @@
#include <limits.h>
#include <asm/xenomai/system.h>
#include <uitron/uitron.h>
+#include <asm-generic/bits/current.h>
extern int __uitron_muxid;
@@ -89,6 +90,8 @@ static void *uitron_task_trampoline(void
if (err)
goto fail;
+ xeno_set_current();
+
/* iargs->pk_ctsk might not be valid anymore, after our parent
was released from the completion sync, so do not
dereference this pointer. */
Index: b/src/skins/vrtx/task.c
===================================================================
--- a/src/skins/vrtx/task.c
+++ b/src/skins/vrtx/task.c
@@ -27,6 +27,7 @@
#include <errno.h>
#include <limits.h>
#include <vrtx/vrtx.h>
+#include <asm-generic/bits/current.h>
extern pthread_key_t __vrtx_tskey;
@@ -106,6 +107,8 @@ static void *vrtx_task_trampoline(void *
if (err)
goto fail;
+ xeno_set_current();
+
/* Wait on the barrier for the task to be started. The barrier
could be released in order to process Linux signals while the
Xenomai shadow is still dormant; in such a case, resume wait. */
Index: b/src/skins/vxworks/taskLib.c
===================================================================
--- a/src/skins/vxworks/taskLib.c
+++ b/src/skins/vxworks/taskLib.c
@@ -27,6 +27,7 @@
#include <errno.h>
#include <limits.h>
#include <vxworks/vxworks.h>
+#include <asm-generic/bits/current.h>
#include "wrappers.h"
extern pthread_key_t __vxworks_tskey;
@@ -117,6 +118,8 @@ static void *wind_task_trampoline(void *
if (err)
goto fail;
+ xeno_set_current();
+
/* Wait on the barrier for the task to be started. The barrier
could be released in order to process Linux signals while the
Xenomai shadow is still dormant; in such a case, resume wait. */
next prev parent reply other threads:[~2008-08-27 14:38 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-27 13:39 [Xenomai-core] [RFC][PATCH 0/3] Handle-based fast mutex owner tracking Jan Kiszka
2008-08-27 13:42 ` [Xenomai-core] [RFC][PATCH 1/3] Always register threads by their base Jan Kiszka
2008-08-27 14:06 ` [Xenomai-core] [RFC][PATCH 2/3] Switch to handle-based fast mutex owners Jan Kiszka
2008-08-27 14:14 ` Gilles Chanteperdrix
2008-08-27 14:38 ` Jan Kiszka [this message]
2008-08-27 14:44 ` Gilles Chanteperdrix
2008-08-27 14:49 ` Jan Kiszka
2008-08-27 14:57 ` Gilles Chanteperdrix
2008-08-27 23:49 ` Gilles Chanteperdrix
2008-08-27 14:36 ` Gilles Chanteperdrix
2008-08-27 14:45 ` Jan Kiszka
2008-08-27 14:47 ` Gilles Chanteperdrix
2008-08-27 14:51 ` Jan Kiszka
2008-08-27 14:55 ` Gilles Chanteperdrix
2008-08-27 15:00 ` Jan Kiszka
2008-08-27 15:04 ` Gilles Chanteperdrix
2008-08-27 15:10 ` Jan Kiszka
2008-08-27 15:13 ` Gilles Chanteperdrix
2008-08-27 15:15 ` Gilles Chanteperdrix
2008-08-27 15:18 ` Jan Kiszka
2008-08-27 15:29 ` Gilles Chanteperdrix
2008-08-27 15:34 ` Jan Kiszka
2008-08-27 15:36 ` Gilles Chanteperdrix
2008-08-27 15:37 ` Jan Kiszka
2008-08-27 23:44 ` Gilles Chanteperdrix
2008-08-27 14:48 ` Gilles Chanteperdrix
2008-08-27 14:50 ` Gilles Chanteperdrix
2008-08-27 15:20 ` Jan Kiszka
2008-08-27 15:28 ` Gilles Chanteperdrix
2008-08-27 15:43 ` Jan Kiszka
2008-08-27 15:46 ` Gilles Chanteperdrix
2008-08-27 16:08 ` Jan Kiszka
2008-08-27 16:13 ` Gilles Chanteperdrix
2008-08-27 18:15 ` Jan Kiszka
2008-08-27 19:02 ` Gilles Chanteperdrix
2008-08-27 19:04 ` Gilles Chanteperdrix
2008-08-27 20:35 ` Jan Kiszka
2008-08-27 21:26 ` Gilles Chanteperdrix
2008-08-27 21:46 ` Jan Kiszka
2008-08-27 21:55 ` Gilles Chanteperdrix
2008-08-27 20:33 ` Jan Kiszka
2008-08-27 22:45 ` Gilles Chanteperdrix
2008-08-28 10:01 ` Philippe Gerum
2008-08-28 10:37 ` Jan Kiszka
2008-08-28 10:52 ` Philippe Gerum
2008-08-28 12:21 ` Gilles Chanteperdrix
2008-08-29 6:41 ` Jan Kiszka
2008-08-29 7:00 ` Gilles Chanteperdrix
2008-08-29 7:22 ` Jan Kiszka
2008-08-29 7:29 ` Gilles Chanteperdrix
2008-08-29 9:36 ` Jan Kiszka
2008-08-29 9:41 ` Gilles Chanteperdrix
2008-08-29 10:37 ` Jan Kiszka
2008-08-29 12:19 ` Gilles Chanteperdrix
2008-08-29 10:39 ` Philippe Gerum
2008-08-29 10:46 ` Jan Kiszka
2008-08-29 12:30 ` Philippe Gerum
2008-08-29 12:40 ` Jan Kiszka
2008-08-29 13:10 ` Philippe Gerum
2008-08-29 13:25 ` Jan Kiszka
2008-08-27 23:05 ` Gilles Chanteperdrix
2008-08-28 7:29 ` Jan Kiszka
2008-08-28 7:38 ` Gilles Chanteperdrix
2008-08-27 23:14 ` Gilles Chanteperdrix
2008-08-28 7:30 ` Jan Kiszka
2008-08-28 8:20 ` Gilles Chanteperdrix
2008-08-28 9:21 ` Jan Kiszka
2008-08-27 14:08 ` [Xenomai-core] [RFC][PATCH 3/3] Remove xnarch_atomic_intptr wrappers Jan Kiszka
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=48B566EC.1020804@domain.hid \
--to=jan.kiszka@domain.hid \
--cc=gilles.chanteperdrix@xenomai.org \
--cc=xenomai@xenomai.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.