Subj : Re: reliability of setting thread priority
To   : comp.programming.threads
From : gottlobfrege
Date : Fri Feb 25 2005 05:27 am


David Butenhof wrote:
> In general, setting "maximum" as the ceiling is a bad idea, because
> you're probably precluding more executable threads than necessary.
> (There may be no alternative if your high priority thread runs at
that
> priority; but this is why THAT'S usually a bad idea.)
>
I feel that I have to assume the worst case - that the polling thread
is at max priority:
- I don't control the whole application, so don't know, and regardless,
don't know what might happen in the future;
- I do work with real time video stuff, where sometimes (rarely)
threads do run at max priority
- in my case, all that happens while at max priority is, basically, a
Win32 InitializeCriticalSection(&cs) - which doesn't take too long.  I
definitely wouldn't allow an arbitrary callback to be happening during
the max 'window'

> Also, you don't show the implementation of your Revert method; but
the
> obvious POSIX implementation would be pthread_setschedparams(), which

> will always bump the thread to the back of its scheduling queue. The
> pthread_setschedprio() function was invented for this specific
purpose,
> and doesn't do that "bump" when lowering priority.
>

Yeah, I was assuming Revert would use pthread_setschedparams(), but
that's just my rough translation of Win32 SetThreadPriority().  Sounds
like pthread_setschedprio() is closer to what I want.  I was wondering
about reordering in the queue, but I couldn't imagine a case where,
since you are a thread and can't assume time slices anyhow, it would
matter that you went to the back of the queue.  Obviously it is
important enough to have a separate function for it.  (I'm not sure
what Win32 SetThreadPriority does in this respect.)

.