Re: [Xenomai] Mutex enhancement for Auto relaxed threads

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2012-11-27 14:46, Gilles Chanteperdrix wrote:
> On 11/23/2012 12:15 PM, Jan Kiszka wrote:
>> On 2012-11-22 17:55, Michael Pustylnik wrote:
>>> Although you can use mutexes in this order, why would you want to do that? Logically, unlocking mutex1 would mean finishing some operation started when mutex1 was locked. If as a part of the operation you locked mutex2 and haven't unlocked it yet, that would mean you haven't completed your operation yet, and unlocking mutex1 at this point would probably be a bug. Am I wrong?
>>
>> I'm not aware that POSIX or some other APIs Xenomai implements forbid
>> such an ordering. And you never know if there is weird convoluted legacy
>> code out there that depends on exactly this.
>>
>> However, I think you can avoid the limitation by attaching the property
>> "trap to kernel on mutex lock" to the thread instead of some mutex,
>> analogously to xeno_current_mode.
> 
> I think the simplest solution to implement this is to share the
> resources count between user and kernel, using a pthread_key in
> user-space. However, I really do not see how to do this without breaking
> the ABI, so, this really is material for xenomai-forge, not for 2.6.

For sure.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux