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 -- Gilles. _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
