Date: Sat, 19 Feb 2005 21:37:42 +0800 From: David Xu <davidxu@freebsd.org> To: Kazuaki Oda <kaakun@highway.ne.jp> Cc: threads@freebsd.org Subject: Re: thread accounting in libpthread Message-ID: <42174126.5000006@freebsd.org> In-Reply-To: <42173C82.7040408@highway.ne.jp> References: <Pine.GSO.4.43.0502181355340.16670-100000@sea.ntplx.net> <42173C82.7040408@highway.ne.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
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
>
>------------------------------------------------------------------------
>
>#include <sys/types.h>
>#include <sys/uio.h>
>#include <err.h>
>#include <pthread.h>
>#include <stdio.h>
>#include <stdlib.h>
>#include <unistd.h>
>
>#define NTHREADS 5
>#define BUFSZ 128
>
>void *func(void *arg);
>
>typedef struct {
> int id;
>} funcarg;
>
>int stop = 0;
>long counts[NTHREADS];
>
>int main(void)
>{
> pthread_t tids[NTHREADS];
> funcarg *arg;
> int rval;
> int i;
>
> for (i = 0; i < NTHREADS; i++) {
> if ((arg = malloc(sizeof(funcarg))) == NULL)
> err(1, "malloc");
> arg->id = i;
> if ((rval = pthread_create(&tids[i], NULL, func, arg)) != 0)
> errc(1, rval, "pthread_create");
> }
>
> sleep(10);
>
> stop = 1;
>
> for (i = 0; i < NTHREADS; i++) {
> if ((rval = pthread_join(tids[i], NULL)) != 0)
> errc(1, rval, "pthread_join");
> }
>
> printf("--------------------\n");
> for (i = 0; i < NTHREADS; i++)
> printf("thread %02d: %ld\n", i, counts[i]);
> printf("--------------------\n");
>
> return 0;
>}
>
>void *func(void *arg)
>{
> char buf[BUFSZ];
> int id;
> int n;
>
> id = ((funcarg *)arg)->id;
> free(arg);
>
> while (!stop) {
> counts[id]++;
> n = snprintf(buf, sizeof(buf), "thread %02d: countup\n", id);
> write(STDOUT_FILENO, buf, n);
> }
>
> return NULL;
>}
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>freebsd-threads@freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-threads
>To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org"
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42174126.5000006>