On 03/01/2014 12:04 PM, Sebastian Kuzminsky wrote: > Taking this discussion from IRC to email, as requested by Michael... > > In the master branch, and in 2.5 and all earlier releases of LinuxCNC, > all HAL threads obey this invariant: short-period threads (ie, the base > thread) are never interrupted by longer-period threads (ie, the servo > thread). > > We provide this invariant in our realtime threads by using RTAI, which > implements rate-monotonic scheduling: > > http://en.wikipedia.org/wiki/Rate-monotonic_scheduling > > We provide this invariant in our "sim flavor" by using libpth (GNU > Portable Threads), which is non-preemptive (so long threads dp not > preempt short threads). > > > The ubc branch changes the scheduling behavior of threads in the 'posix' > flavor, which is most similar to 'sim builds' in master and earlier. > The posix flavor does not match our invariant. > > In ubc's posix flavor, hal threads are implemented by posix threads, > which by default do not provide any scheduling invariants. This means > scheduling is unpredictable, and shorter-period threads can be > interrupted by longer-period threads.
Going by `man 2 sched_setscheduler`, POSIX threads are normally scheduled under SCHED_OTHER, and all have the same priority of 0. Michael's patch simply enables for POSIX threads the SCHED_FIFO scheduler, the same (shared) code that allows PREEMPT_RT threads to have non-zero priorities and the characteristic you describe where higher priority threads will not be preempted by lower priority threads. (The period of the thread is not automatically related to its priority, as the wikipedia article implies; in LinuxCNC, in all RT flavors, the base thread is explicitly given a higher priority than the servo thread, and the base thread also, independently, has a shorter period than the servo thread.) Looking at your buildbot, I see that some 'rip' builders (e.g. 1201.rip-lucid-rtai-i386) have a step named 'compile_1' which runs 'make setuid'. Other 'rip' builders (e.g. 1300.rip-precise-i386) skip this step. Because of the recent builder name changes, the link to the failed build referenced from the original IRC conversation [1] is broken, but if builders following the new <index>.<build-type>-<distro>-[<kernel>-]<arch> naming scheme that have no <kernel> element in the name and omit the 'make setuid' step are posix builds, this would explain the problem: In order for sched_setscheduler() to set a non-zero priority, which posix 'sim' threads need to guarantee non-preemption of higher-priority threads, the 'make setuid' step must not be omitted. In summary: Re-enable the 'make setuid' step on the buildbot, and I bet the threads.0 test will pass again. > However, for conceptual consistency I would like to see all kinds of HAL > threads meet the same invariants. Michael started work towards this > goal here, but it's not finished: > > > http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commitdiff;h=30301356cab8bb17122de6a59bcc65a28b5981a5 If this patch is not finished, then it's only because there should be some initial detection of whether non-zero priorities may or may not be set, and a meaningful error produced in the latter case. (Same goes for PREEMPT_RT threads.) John [1] http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2014-02-28.html#18:24:32 ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
