Seb, I reply under new subject as I want the 'ubc: inconsistent behavior in posix flavor vs others' thread remain focused exclusively on the rather fundamental synchronisation question discussed there. That is too important too blur with code reading guidance.
I hope that is ok with you. Am 04.03.2014 um 18:40 schrieb Sebastian Kuzminsky <[email protected]>: > On 3/1/14 11:04 , Sebastian Kuzminsky wrote: >> (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...) > > I'm requesting education about UB. > > In 2.5 and master we have the following behaviors: > > * the low-priority thread (the servo thread) does not interrupt the > high-priority thread (the base thread) > > * the high-priority thread (base thread) and the low-priority thread > (servo thread) do not run concurrently on different processors > > RTAI and libpth provide these behaviors. > > (This all made sense when computers had a single processor, and it > probably does not make sense now that computers have multiple > processors, but that is not the discussion i want to have in this thread.) > > > In UB there are four(?) new thread styles: xenomai-kernel, xenomai, > rtpreempt, and posix. (That's in addition to the rtai thread style > which is the same as the rtai thread style in 2.5 & master.) > We know that posix threads do not preserve the scheduling behaviors > above, this was revealed by the threads.0 test. modulo rtapi_app privilege setting as discussed already, yes. > I do not know if the remaining three thread styles preserve the > scheduling behaviors, and if they do, what the mechanisms that implement > this behavior are. > John or Michael, can you illuminate the issue? Sure. To answer that question you need to look per-flavor at two aspects : - thread creation and startup - setting of scheduling attributes in this context, if any. There is no change of thread properties post-creation. the pertinent files are src/rtapi/{xenomai,xenomai-kernel, rtai-kernel, rt-preempt}.{c,h} . In the UB code this means looking at the following handlers for the full picture: _rtapi_task_new_hook() - thread creation (thread is NOT started by this). This sets priority, stacksize, cpu binding, fp use, pointer to code. _rtapi_task_start_hook() - thread is started. That is where the thread period is set. Note some flavors have task_new and task_start separate, some have it collapsed into one hook only where that made sense as suggested by API semantics, or such was the code I integrated. Then you read the documentation of the pertinent system calls or kernel services and convince yourself it does what it should. Repeat that process for all flavors. example: xenomai.c - _rtapi_task_new_hook() here: http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/rtapi/xenomai.c;h=b81da72b3c8fbe6e3f0ddc392b1dd9cd0c3ce96c;hb=refs/heads/unified-build-candidate-3#l272 so next you need to read up on rt_task_create() for example here: http://www.xenomai.org/documentation/trunk/html/api/group__task.html and read up on xenomai scheduling. xenomai-kernel uses the same API with minimal deviations. rt-preempt.c (covers also posix): beyond _rtapi_task_start_hook(), read realtime_thread(), realtime_set_affinity() (CPU binding), realtime_set_priority() - sets scheduling priority. Start here: http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/rtapi/rt-preempt.c;h=1bb79f285683b9f6ec20ae653719428554eb9f88;hb=refs/heads/unified-build-candidate-3#l331 so for your question read realtime_set_priority() , and consequently read man sched_setscheduler . rtai-kernel is as before. I thought that code had long since been reviewed by you guys, at least that's what we've been hearing for quite a while now. Suprised to see we are still at this early stage. - Michael ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
