Am 01.03.2014 um 19:04 schrieb Sebastian Kuzminsky <[email protected]>:
> 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. > > (Now that i think about it, ubc has three flavors that use userspace > threads, all presumably implemented by posix threads: posix, rt-preempt, > and xenomai-user. I dont know how things work in the rt-preempt and > xenomai-user flavors, hopefully their scheduling somehow matches our > invariant. If not, that would be bad...) > > This is not a huge problem in practice, because sim configs (and by > extension, ubc's posix configs) generally only use one thread. So the > change in behavior should be masked by our current set of use cases. > > 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 > > > So this email is an explanation of what i think the problem is, what i > think the fix is, and a request for Michael to finish the work. You forgot to say what is 'unfinished'; I did cite the issue in IRC today [08:41am], as you have certainly seen: > re setcap: yes, one would have to add that step, provided it is important - > the commit only shows how it can be done, but it doesnt do it > of the actual sim configs, I am not aware of any which have more than one > thread, so this would be about the runtest only - the question is: is it > worth that > if yes, we have a new pkg dep, and a command to add during make setuid So it is a _decision_ to take, and it is: do we fix something which is not used right now at all, at the expense of a package dependency, and a 'sudo make setuid' step? Or do we just document the behavior and the steps required in case somebody actually needs this? Both occur to me as sensible routes, but you do not indicate which one you prefer. So state here which route you prefer, and we can go from there based on what comes out of this thread. My vote is to document the behaviour, and adapt the runtest to take care of it. the alternative which I have heard from Chris - returning to Gnu pthreads - is a support issue in the making: this library has pretty much fallen into disuse and has not seen a commit in 8 years. Going back also forfeits the upside of using the same code - modulo an ifdef - for both posix and rt-preempt, which was the motive for the switch to start with. As for your first sentence, I do not think requesting a fundamental issue to be discussed on the developer list is something which warrants an ellipsis at the end of a sentence. To the contrary, I think the habit of making decisions on IRC is inappropriate as it excludes folks which do not follow IRC but read emc-developers only, and this should be stopped. - Michael > > -- > Sebastian Kuzminsky > > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
