thread accounting in libpthread

Kazuaki Oda kaakun at highway.ne.jp
Sat Feb 19 05:44:49 PST 2005


Yes.  It is fair scheduling under console.  My result is under xterm.
Could you run it under xterm or any other x11 terminal?


David Xu wrote:

> I have run your program, here is the result:
>
> ...
> thread 04: countup
> thread 00: countup
> thread 01: countup
> --------------------
> thread 00: 553150
> thread 01: 562367
> thread 02: 553351
> thread 03: 532770
> thread 04: 542718
> --------------------
>
> It is fair scheduling. I run it under console and no other programs 
> are eating CPU
> time, note that I didn't run it under X11 terminal.
>
> David Xu
>
> 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
>> 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.
>>
>> The reason why I am researching libpthread is that the attached 
>> program shows
>> --------------------
>> thread 00: 55666
>> thread 01: 1161
>> thread 02: 1112
>> thread 03: 1112
>> thread 04: 55494
>> --------------------
>> on xterm on my UP machine.  This is a unexpected result.  It seems to 
>> me that
>> libpthread does unfair scheduling.  But on SMP machine that program 
>> shows
>> expected result and on console too...
>>
>>
>> --------------------
>> Kazuaki Oda
>>



More information about the freebsd-threads mailing list