On Wed, 14 May 2008, Andriy Gapon wrote:

quoted text
> 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.

The behavior of scheduling with respect to mutex contention (apart from
pthread_mutexattr_setprotocol()) is not specified by POSIX, to the best
of my knowledge, and thus is left to the discretion of the  implementation.

quoted text
> Is there any option (thread scheduler, etc) that I could try to achieve
> "good" behavior?

No portable mechanism, and not any mechanism in the operating systems
with which I am familiar.  That said, as the behavior is not specified
by POSIX, there would be nothing preventing an implementation from
providing this as an optional behavior through a custom
pthread_mutexattr_???_np() interface.

quoted text
> 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.

As other responders have indicated, the behavior you desire is as
unoptimal as possible for the general case.  If your application would
truly benefit from this sort of queuing behavior, I'd suggest that
either you need to implement your own mechanism to accomplish the
queueing (probably the easier fix), or that the threading architecture
of your application could be designed in a different manner that
avoids this problem (probably the more difficult fix).

Brent

-- 
Brent Casavant			Dance like everybody should be watching.
www.angeltread.org
KD5EMB, EN34lv
_______________________________________________
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"