>> I seem to have this problem:
>> Process Proc is started in real time, it in turns creates THR_BOUND thrA.
>> And then it drops itself in time share queue and creates THR_BOUND thrB.
>>(Actually there are a multitude of time-share and real-time threads.)
>> Now thrA runs for a while (some milliseconds, say 15 ) and then it sleeps
>>for some milliseconds. (This is actually done by some interrupt mechanism
>>but that probably is not important either) and then thrB comes in prints some
>>data generated by thrA and goes to sleep. So far so good. Now however
>>if I go to another window and do an "ls" or another command, what I am
>>seeing is that if "ls" starts when the time-share thread thrB is running,
>>it can preempt thrB, and when the time to run thrA comes again, scheduler
>>doesn't necessarily run thrA.
>Possible causes I can think of:
>1. By any chance does thrB acquire a lock to read the data produced by thrA,
> and so prevent thrA from running if thrB is blocked in a critical section?
No. No mutexes are shared between real-time and time-share threads.
All the message passing is done thru queues (Ala Aho, Hopcroft et al...)
Quote:>2. By "drops itself in time share queue" do you mean a priocntl call
> that sets only the lwp of the main thread? Or are you using the P_PID
Yes. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Quote:> option. The later case will _not_ do what you want; it sets all the lwps
> of the process back to the timeshare class. Since the main thread is not
> bound to an lwp I would be very careful to make sure that no extraneous lwps
> exist which could run the main thread in a different class than you expect.
This actually may be the problem, since we get symptoms that there may be
a rogue thread (renegade or whatever you want to call it...).The only
ointment in the fly is tho' main thread does not do anything.(it is
suspended). BTW if you repeatedly do a ps -c then you see that the
scheduling class changes between TS and RT.
Quote:>3) The ls command isn't doing output directly to the system console, is it?
> (E.g. with no window system running) The kernel handles raw console IO at
> a much higher priority than you might expect.
No , we are running olwm/cmdtool/xterm.
Quote:>Is the system idle when the thrA isn't running, or is the ls still going as
>assumed in the possible causes above?
thrA does all the hardware in the loop I/O and then does an ioctl,
which waits on a cv_wait which gets cv_signalled when a timer interrupts
comes in. What almost appears that when the cv_signal comes in , the
scheduler checks to see if there are any PROCESSES in the real-time queue,
if there isn't then it assumes that there is no real-time lwp's running
either.(I know this is a reach but I can't guess anything else that is
happening.) Yesterday, I changed the scheme to that now I no longer
drop the process out of the real-time queue, instead I boost the
priority of thrA (actually they are 4 threads) by 10. It worked
like a charm. Therefore the problem seems to be when there are
real-time lwp's associated with a process but when the process itself
is in the time-share.
BTW How does one get rid of the rogue lwp?. Seems the system creates
one just in case you have unbound threads. I do not quite understand
the main thread not being bound to a lwp...
Sinan
Quote:>Hope this helps -
>- Bart Smaalders Solaris Performance SunSoft
by