Jan Kiszka wrote:
> 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 all skins (except for
>>>>> RTDM which must not mess around with foreign skins anyway) add their
>>>>> threads to the registry so that at least anonymous handles are
>>>>> available.
>>>>> 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.
>>>> The current implementation allows RTDM threads to use POSIX skin
>>>> mutexes. I do not see why this should change.
>>> Such mixup might technically be possible now. But there is neither a
>>> need nor does it make the resulting driver more portable. I don't want
>>> to introduce needless thread registration to RTDM just to cover
>>> theoretical use cases that should not exist in the first place.
>>> Nevertheless, some sanity check will have to be added to the
>>> to-be-written generic xnsynch support to catch missing thread handles.
>>> That make sense for checking future skin implementation as well.
>> That is overhead in the hot path, whereas adding the thread registration
>> takes place in a non hot path.
> It will be a debug check.

On the other hand: Once we really have generic fast xnsynch support,
this discussion should become pointless - RTDM will use them for its own
mutexes as well. So let's look at this patch only for the current
situation where there is no need for RTDM threads to have a handle as
they must not mess with foreign skin objects.


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

Xenomai-core mailing list

Reply via email to