thread accounting in libpthread

[David Xu]

Refreshed, I got it under x11:

--------------------
thread 00: 25925
thread 01: 57635
thread 02: 24947
thread 03: 1187
thread 04: 13166
--------------------

the result seems a bit unfair. :)


Kazuaki Oda wrote:

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