thread accounting in libpthread

[Kazuaki Oda]

Daniel Eischen wrote:

> 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.


Sorry for my misreading.  I've understood what you mean.


>
>> 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?
>

No,  I have not changed.  kse_check_completed() is called after kse_wait().
What I meant in the past e-mail was that in such case there was no 
running thread,
and so we did not needlessly switch it out.

Thanks.


--------------------
Kazuaki Oda