[M3devel] results of threadtest program on Windows7

Mika Nystrom mika at async.caltech.edu
Sun Feb 27 00:10:55 CET 2011


Jay K writes:
>--_fe2b6a60-67dc-46f1-b844-2023fbc40258_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>Thanks.
>
>jbook2:thread jay$ ./I386_DARWIN/threadtest=20
>Writing file...done
>Creating read threads...done
>Creating fork threads...done
>Creating alloc threads...done
>Creating lock threads...done
>running...printing oldest/median age/newest
>..........laziest thread is 1/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 1/0/0=
> lock 1/1/1)
>..........laziest thread is 1/0/0 (tests: read 1/0/0 fork 1/1/0 alloc 0/0/0=
> lock 0/0/0)
>
>those aren't errors=2C right?

No those are just the noral diagnostics.  The numbers are how many
seconds the various threads are lagging.

User threads do have a "more unfair" scheduler than you can expect with Darwin
(see comments in the code)...

You can change the number of threads etc but I find that the defaults seem to
catch stuff.  Lowering the number of threads per test from default 3 to "-n 2"
simplifies debugging, perhaps.  (More comments in the code.)

    Mika

>
>I can reproduce problems on Darwin -- assertion failures=2C errors in Threa=
>dPThreadC.c like EBUSY and I think EINVAL.
>  EBUSY is from pthread_mutex_destroy=2C which means we are freeing a mutex=
> while it is locked=2C which means
>   there is a problem. Such as the garbage collector collecting non-garbage=
>. It ccould be something else though.
>
>I'm trying with user threads. User threads do print the above. But so far h=
>as a longer runtime than with pthreads=2C
>  hasn't hit any SIGSEGV or assertion failure or anything yet.
>
>I do wonder .. oh=2C and then w/ user threads:
>
>All tests complete.  Congratulations.
>
>I do wonder about scheduling order and when the preemptions occur.
>For example user threads does offer Disable/EnableScheduling.
>Maybe the timeslices vary a lot and userthreads preempt a lot less?
>Maybe we can try w/ tuning the user thread timeslice to match whatever pthr=
>ead uses on whatever platform (
>there likely no guarantee or documentation=2C but for experimental purposes=
> we can likely figure it out
>experimentally).
>
>It will be interesting to see the results on Windows too. I'll probably try=
> that right away.
>
> - Jay



More information about the M3devel mailing list