Re: [Lmuse-developer] 2.6 thread scheduling fix

[Fernando P. Lopez-L. <na...@cc...>]

On Sat, 2004-08-14 at 20:45, John Check wrote:
> On Saturday 14 August 2004 04:13 am, Werner Schweer wrote:
> > On Friday 13 August 2004 23:52, Fernando Pablo Lopez-Lezcano wrote:
> > > On Fri, 2004-08-13 at 14:17, Robert Jonsson wrote:
> > > > Werner,
> > > > About the recent discussion about lousy functionality under 2.6 it was
> > > > discovered that performance could be drastically improved by setting
> > > > the scheduling priority for the jack-thread to a higher number.
> > > >
> > > > I have a number of open questions about this.
> > > >
> > > > For starters I was wondering if this priority is not supposed to be set
> > > > by jack, and this being the reason it was set to a very low value?
> > >
> > > It is supposed to be set by Jack.
> >
> > thats right. MusE checks the Jack thread for SCHED_FIFO. If not,
> > MusE sets SCHED_FIFO and priority. This is only a workaround for
> > erratic 2.6 behaviour.
> > I just installed a new glibc (2.3.4-20040701) and the bug disappeared so
> > i believe its related to the nptl libray.
> >
> > > > If this is not the case, are there any drawbacks to setting the value
> > > > to, say 50 instead?
> > >
> > > At least one I can think of, the watchdog process within Jack will not
> > > work. An error in Muse could hang the machine because the watchdog
> > > process would not be scheduled (I'm positive the watchdog process is
> > > running with a priority higher than all other Jack threads).
> >
> > the watchdog thread should have the highest priority of all threads.
> > MusE sets up a watchdog thread of its own with the highest possible
> > priority.
> > There is another RT thread in MusE to schedule midi events. This
> > Midi thread must have higher priority than the jack thread. If not
> > you get some midi events quantized to the jack period size.
> >
> 
> It seems like a bit of a paradox to expect more than one realtime thread
> to perform as realtime (by whatever definition). Wouldn't there be some sort 
> of contention once you hit N processors +1 threads?

"Realtime" in the context of this thread is twofold, one is that the
process has priority over any other non-realtime process, the other is
the process will run until it volutarily relinquishes control. Other
than that realtime processes will have to share the cpu by executing one
after then other, in order of priority and readiness to run. Jack itself
uses multiple realtime processes (I think three on the server plus one
per client). 

-- Fernando