Subj : reliability of setting thread priority
To   : comp.programming.threads
From : gottlobfrege
Date : Wed Feb 23 2005 08:24 pm

How reliable/portable/etc is messing with thread priorities?  What do I
mean?  Well, let me explain the story:
  In particular, similar to the problems of static local initializers
and implementing pthread_once, etc., I want to initialize a critical
section in a thread safe manner. I would use another critical section
to guard the first CS, but that 'begs the question' as they say. :-)  I
could use a global named mutex (CreateMutex() under Win32), but that
seems a bit heavy - and if I was going to use a mutex to make a
criticalsection, maybe I should just use a mutex where the CS was going
in the first place.  So I'm left with using one or two global
variables, and using atomic get and sets, etc., to manage them.

The only problem left is that since I can't use a CS or mutex, the
second thread in must poll to wait for the first thread to finish.
Which is fine, except if the second thread has a higher priority and
thus starves the first thread.  So I'm wondering if I can reliably mess
with the thread priorities to handle that problem.  This works (I
think) under Windows, but I'm wondering if it would work under other
systems (ie POSIX systems, using pthread_setschedparam, etc.  Am I
wrongly assuming 'round-robin' scheduling, etc?  How common are various
scheduling rules?).

And I'm wondering what other problems there might be.  ie, yes, I
understand that I am opening myself up to a boat-load of criticism. :-)
 In particular, I can imagine memory-visibility/cache-coherency
problems (thus the use of Atomic operations), and also problems if the
1st thread dies (ie exception, etc) before completing its task, thus
leaving the 2nd thread waiting/polling forever. etc.


....Well, anyhow, here's some code.  I hope most of the context and
objects make sense.  ie 'cs' is a critical section,
ThreadPriorityMaximizer is a class that sets the current threads
priority to max on construction, and back down to whatever it was on
destruction, etc:

         {
		ThreadPriorityMaximizer maximizer;

		if (!AtomicExchange(&entry, true))
		{
			// we are in, and at max priority

                  // init our critical section:
			cs.Init();
			AtomicExchange(&initted, true);
		}
		else
		{
			// we are not in, but _still_ at max priority
			// better lower our priority before we just sit and spin at max!
			maximizer.Revert();

			while (!AtomicRead(&initted))
			{
				Sleep(1);
			}
		}
         }

well, what do you think?

Tony

.