On 10/10/2012 03:57 PM, Philippe Gerum wrote:
>> Except if we invent another scheduler lock service, simply for the
>> purpose of spinlocks where suspending the spinlock holder does not make
>> sense anyway.
>>
>
> Oh, well, ok. Ack.
>
> Let's just make sure that we can fold the whole thing into a single set
> of services at some point in 3.x though.
>
> The core issue is that we should not even have to expose a scheduler
> locking service to userland, but emulating traditional RTOS APIs
> requires that. What a braindamage counter-feature for a real-time system
> when one thinks of it.
I think we can have the cake and eat it. The idea is to follow the
approach in the patch I sent, merged with the one you commited, but
simply, in xnpod_suspend_thread, clear the XNHELDSPIN (misnomed if used
for that), and simply when we wake up, re-set the bit in the scheduler
if the thread preemption count is not 0.
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
