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