Andriy Gapon wrote:
quoted text
> 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-threads@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-threads
To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org"