Coming from the hardware world, I would argue that threads must be assumed to operate in any order, and at any time, including fully concurrently on a multi-core system. IMHO anything less limits the ability to make use of modern system and in particular the work Michael is doing that provides for the possibility of multiple concurrent real-time "islands" that all talk to each other (potentially running on different cores, CPUs, or even different machines). Even embedded ARM systems are beginning to have multiple cores, so limiting multiple real-time threads to serial execution is already potentially performance limiting.
If software requires tighter coherency or ordering specifications between threads, mechanisms can be added to do this (by the user code or on the RTAPI side if it's a common enough need), but it sounds like this isn't generally relied on, it just always worked that way. IMHO that's not enough of a reason to paint ones-self into a corner going forward. On 3/1/2014 2:38 PM, Michael Haberler wrote: > > 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 > -- Charles Steinkuehler [email protected]
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
