Le 05/11/2012 19:46, Gilles Chanteperdrix a écrit :
On 11/05/2012 02:33 PM, Thierry Bultel wrote:
Le 11/10/2012 10:05, Gilles Chanteperdrix a écrit :
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.
Hi,
sorry to come on that thread again, but it is not clear to me if the
issue has been adressed or not.
I have noticed the "nucleus: introduce internal sched locking helpers"
commit, that seems related but I am not sure.
Sorry for the noise.
I have posted a patch, and await Philippe's approval. The patch may have
some dubious side effects, it is here:
http://www.xenomai.org/pipermail/xenomai/2012-October/026523.html
Thanks a lot,
I will also try it asap
Thierry
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
