[gclist] Mars Rover info from comp.risks

[Hans Boehm]

A minor correction:

On Jan 7,  2:03pm, Bill Burcham wrote:
> I wrote:
> >  (I think this all works with a pthreads-like interface, but it
> results in
> > spurious context switches.  If a resource becomes available, I usually
> will
> > call pthread_cond_signal while holding a lock.  I then lower my
> priority,
> > usually causing me to lose the processor while still holding the lock.
> The
> > high priority thread will the run and try to reacquire the lock,
> bumping my
> > priority up again, and suspending itself again.)
>
> Sounds to me like the reason for the spurious context switch in your
> scenario is that you fail to release the lock before deflating your
> (artificially inflated) priority.  Why can't you just release the lock
> first, and _then_ change your priority, _then_ call pthread_cond_signal.
>
That doesn't work, since you'll normally get suspended when you change your
priority, thus never getting a chance to signal the condition.  If you
reverse the last 2, you still have at least one race condition.
A third thread trying to raise your priority can get
in the middle, and you will imediately undo that.  Thus you can, in the worst
case, end up with the original priority inversion again.

> This whole priority scheduling thing has to go!  It is just wrong.

For the kinds of things I do, I certainly agree.

Hans




-- 
Hans-Juergen Boehm
boehm@mti.sgi.com