thread accounting in libpthread

[Daniel Eischen]

On Sat, 19 Feb 2005, Kazuaki Oda wrote:

> Daniel Eischen wrote:
>
> >On Sat, 19 Feb 2005, Kazuaki Oda wrote:
> >
> >>And while looking at thr_kern.c, I've had one more question.
> >>In kse_switchout_thread, after calling thr_accounting thread is placed
> >>at the tail of run queue or at the head of it according to
> >>thread->slice_usec.
> >>But in kse_check_completed, thread is just placed at the tail of run queue.
> >>Is there any reason why thread is not placed at the head of run queue in
> >>case of thread->slice_usec != -1?
> >>
> >>
> >
> >Because it already blocked and we don't want to needlessly
> >switch out a currently running thread that hasn't used its
> >quantum.
>
> Blocked?  I think that completed threads are *not* blocked and they are
> ready

Blocked is past tense above.  It _had_ blocked in the kernel
and that gave other threads a chance to run.  You don't add
it to the head of the queue because that makes it unfair to
the other threads that were in the queue.  The default
scheduling is SCHED_RR in libpthread and that is laid
out by POSIX.

> to run except for suspended.  And, kse_check_completed could be called after
> calling kse_wait.  In this case there is currently no running thread.

kse_check_completed() is called after kse_wait().  Do you
have local changes that removed it?

-- 
DE