Andriy Gapon wrote:
I am trying the small attached program on FreeBSD 6.3 (amd64,
SCHED_4BSD) and 7-STABLE (i386, SCHED_ULE), both with libthr as threads
library and on both it produces "BROKEN" message.
I compile this program as follows:
cc sched_test.c -o sched_test -pthread
I believe that the behavior I observe is broken because: if thread #1
releases a mutex and then tries to re-acquire it while thread #2 was
already blocked waiting on that mutex, then thread #1 should be "queued"
after thread #2 in mutex waiter's list.
Is there any option (thread scheduler, etc) that I could try to achieve
"good" behavior?
P.S. I understand that all this is subject to (thread) scheduler policy,
but I think that what I expect is more reasonable, at least it is more
reasonable for my application.
In fact, libthr is trying to avoid this conveying, if thread #1
hands off the ownership to thread #2, it will cause lots of context
switch, in the idea world, I would let thread #1 to run until it
exhausts its time slice, and at the end of its time slices,
thread #2 will get the mutex ownership, of course it is difficult to
make this work on SMP, but on UP, I would expect the result will
be close enough if thread scheduler is sane, so we don't raise
priority in kernel umtx code if a thread is blocked, this gives
thread #1 some times to re-acquire the mutex without context switches,
increases throughput.
Regards,
David Xu
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
