SMPing libpthread

[Terry Lambert]

David Xu wrote:
> From: "Daniel Eischen" <eischen at pcnet1.pcnet.com>
> > David, I noticed that we hold the scheduling lock before and
> > after calling the scheduler.  Is this necessary?  And if so,
> > is it necessary to hold hold it after return from the
> > scheduling switch?  One you're in the scheduler, and choose
> > another thread (releasing the lock after doing so), shouldn't
> > you be able to switch to it without having the lock?
> 
> I am trying to do things in atomic way. because I found on SMP,  thread
> state is always out of synchronized in current code.  I want to make
> state change and context switch in an atomic operation,  when thread is
> in state transit,  no other threads can use _thr_setrunnable_unlocked()  etc
> to change its state,  this avoids lots of "thread already in priority queue"
> messages,  and if  I test the "in priority queue" flag every where, I sometimes
> lose chance to wakeup a thread because of some unknown races, whole
> process just suddenly stops there.  I am just copying the idea from
> current kernel code,  I don't intend to inventing new things. :-)

Note that I think you want idempotence, not atomicity, in this
case, anyway.

Jeff and Julian should comment; but my gut feeling is that
you should be passing a function to the scheduler for it to
call on your behalf, while it holds any locks it feels are
necessary.  This is probably an interface layering violation
for the scheduler API.

I can't help feeling, though, that this should be seperated
out.  I don't know how to deal with the idempotence issues
"correctly", and still maintain a seperation between threads
implementation and scheduler implementation off the top of
my head (at least, without changing the scheduler API), but
I'm sure it's doable, with a little thought.

-- Terry