<br><br><div><span class="gmail_quote">On 3/2/06, <b class="gmail_sendername">Brian Neal</b> <<a href="mailto:bgneal@gmail.com">bgneal@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello,<br><br>We are using omniORB 4.0.6 on a Monta Vista Linux embedded system.<br>This Linux variant has special real-time support built into it that is<br>activated when you pick the SCHED_FIFO pthread priority policy.
<br>Threads that use SCHED_OTHER get the default Linux<br>scheduling...basically the SCHED_FIFO threads will run in a real-time<br>fashion before all SCHED_OTHER's get a chance.<br><br>>From studying the omniThread source, it looks like the omniThread
<br>library is using SCHED_OTHER when running under POSIX.<br><br>We have instrumented our code where we make a CORBA call on the client<br>and then where the servant receives the call, and are seeing a lot of<br>jitter. Sometimes the call may take 700 usecs and sometimes
1.5x that.<br>We suspect that if we were to get the CORBA threads into the<br>SCHED_FIFO class, this jitter would go away. We suspect that even our<br>lowest priority SCHED_FIFO threads are preventing the SCHED_OTHER<br>CORBA threads from running.
<br><br>Currently there doesn't seem to be a way to tell omniORB what priority<br>it should use for its threads. Does it just pick the omniThread<br>PRIORITY_NORMAL? Is there a way to pass an arg to the orb for that?<br><br>
We are fully prepared to go into the omniThread/posix.cc file and<br>start hacking, but we wanted to run that by the list (and Duncan)<br>first. It would be nice if we could specify the scheduling policy<br>(maybe via a -D at build time) and then if omniORB provided hooks to
<br>set thread priorities we would be all set. We would be glad to provide<br>a patch if we get it all sussed out nicely. But I suspect we will just<br>modify that posix.cc file for now to set the policy and hardcode some
<br>suitable priority and see what happens. Thoughts?</blockquote><div><br>
we encountered the same problem and patched the posix.cc file to inherit sched params from parent thread by adding:<br>
<br>
THROW_ERRORS(pthread_attr_setinheritsched(&attr, PTHREAD_INHERIT_SCHED));<br>
<br>
in the omni_thread::start() function. Helps to make everything running with FIFO is parent thread is.<br>
Other possibility if to use the createThread interceptor to have finer controls.<br>
<br>
renej<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">(I realize it is difficult for a general purpose thread abstraction<br>layer like omniThread to please all underlying OS's...we have a thread
<br>abstraction class like this too and have encountered the same<br>agonizing design decisions.)<br><br>Thank you.<br>BN<br><br>_______________________________________________<br>omniORB-list mailing list<br><a href="mailto:omniORB-list@omniorb-support.com">
omniORB-list@omniorb-support.com</a><br><a href="http://www.omniorb-support.com/mailman/listinfo/omniorb-list">http://www.omniorb-support.com/mailman/listinfo/omniorb-list</a><br></blockquote></div><br>