Thread scheduling: priority meaningless?

Thread scheduling: priority meaningless?

Post by Gil Ten » Sun, 19 Mar 1995 18:25:14



How can you control which LWP your thread is scheduled in???

What good are thread priorities and pre-emptive thread scheduling
if you cannot dictate which threads run under which LWP?

I've run into an interesting "feature" in Solaris threads. I'm building
MT apps on Solaris 2.4 x86, and from reading Sun's docs on threads, thread
scheduling seemed to be very nice. I especially liked the fact that
scheduling between threads (within the same LWP) is apparently pre-emptive
and deterministic -- the docs repeatedly state that there cannot be a
situtation where a high priority thread is ready to run in the LWP
but isn't.

Using this fact, I schedule two threads to run with a clear priority
between them. Thread 1 (lower priority) utilizes a resource for
about 250ms, and locks a mutex around it. it then frees the mutex,
but almost immediately grabs it again for another 250ms, and so
on for 1 minute... Thread 2 (higher priority) wakes up every 10 seconds,
and wants to briefly use the same resource, attempting to lock it's
associated mutex. At this point, it should have to wait at most 250ms
for the lower priority thread to release the mutex. The mutex release
call should immediately pre-empt the lower priority thread, and switch
to the higher priority thread, giving it the mutex.

In reality, Thread 2 (higher priority) doesn't get the mutex at all
until the lower priority thread completes (after 1 min). It seems to
be racing for the same mutex, but it does not pre-empt the lower
priority thread. Since the pre-emption doesn't happen, the lower
pririty thread holds on to the mutex for 250ms and releases it
for only a few microseconds in each cycle. Under these condictions
the higher priority thread has virtualy no chance of grabbing the mutex
away...

The only explanation I can find for this is that all the nice
pre-emption features are documented to work between threads in
the *same LWP*. Apparently my threads are scheduled to different
LWP's, and since I don't set those to a real-time priority class,
they use the normal "fair" scheduling between them, with no inter-LWP
pre-emption, leaving the "higher priority" thread hung waiting...

Alas, I find no way of forcing two threads to reside in the same
LWP. As long as this cannot be done, inter-thread priority is virtually
meaningless. Since there is no way of telling which LWP a thread will
end up in, there is no way to design for "deterministic" inter-thread
behaviour in an M.T. program (with the exception of assigning each thread
a bound, Real Time class LWP). Needless to say, R.T Class LWPs have
the BIG drawback of* your system frequently if your own thread
code is buggy (a near certainty when under development).

Ideas, suggestions, or explanations, anyone?

AdvThanks,

--
---------------------------------------------------------------------
-- Gil Tene        Cloud Seven, Inc.    "Some days it just     -
-- (415)-254-0910  172 Ada Ave #10         doesn't pay to go to     -

---------------------------------------------------------------------

 
 
 

Thread scheduling: priority meaningless?

Post by Bil Lew » Wed, 22 Mar 1995 06:42:53


Gil,

  Tough question!  If I read it right, you're doing something sort of funny,
having a thread that wakes up (via a timer?) every 10 seconds.  If there is
only 1 LWP, and said thread (T1) BLOCKS on mutex M, then when the owner (T2)
of M releases it, T2 will run the scheduler, which will select T1 to run.
(No preemption even involved here!)  If you have TWO LWPs, then both threads
will be able run run at the same time, and T2 will have a 99% probability to
reacquiring M.

  Hmmm...  I think I need to sit down and think about this longer...  (Do you
have a 50 line example program?)

-Bil
--
Det ?r den som g?r vilse, som finner de nya v?garna


Developer Technical Evangelism

 
 
 

1. thread scheduling and priority

  I would like to specify control execution priority for a set of unbound
  threads in our application (for both Solaris and Posix threads). In a
sample
  test program, the corresponding threads APIs (set/get) do indicate
  the priorities have been changed.

  My questions are:

  - Do I need to suspend a Solaris thread before changing its priority?
    The man page is not very clear on this.

  - Is the thread priority fixed or effected by the cpu (etc) usage by that
    thread?

  - How does the thread priority map to the priority displayed by "ps -L"?
    Are these LWP's priorities? This priority seems to change (as per
    kernel time-share scheduler) per cpu usage etc.

  - What is the benefit of changing thread priority in a time-share
scheduling
    mode?

  vipul patel

2. color cmdtool support -- anyone done this?

3. Thread priority scheduling across linux kernels.

4. where is the error ? find . -mtime +30 |mv ...

5. Thread Scheduling Priorities

6. IPv6 on Linux 2.4.19 over Token Ring?

7. Quick Q on kernel threads and RT thread priorities

8. Staircase effect on a remote printer

9. Performance improvements binding threads to CPUs or thread priorities

10. Thread scheduling in Solaris threads

11. Setting Schedule Priority

12. Running consoles with low scheduling priority?

13. [patch] batch/idle priority scheduling, SCHED_BATCH