Skip site navigation (1)Skip section navigation (2)
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>