Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> 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?
> I prefer my application to die. This way I would know that something
> went wrong. And by the way, how could this syscall fail ? I mean if
> xenomai or the posix skin are not loaded, we would have known it earlier.

So far this syscall can trigger a thread handle registration if the
current thread has no handle yet. But that could go away if all skins
ensure that there is at least an anonymous handle for their threads
after creation.


Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Xenomai-core mailing list

Reply via email to