Date: Wed, 14 May 2008 17:29:30 -0700 From: "David Schwartz" <davids@webmaster.com> To: <freebsd-threads@freebsd.org>, <freebsd-stable@freebsd.org> Subject: RE: thread scheduling at mutex unlock Message-ID: <MDEHLPKNGKAHNMBLJOLKCEGGMKAC.davids@webmaster.com> In-Reply-To: <482B0297.2050300@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. >=20 > I compile this program as follows: > cc sched_test.c -o sched_test -pthread >=20 > 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. >=20 > Is there any option (thread scheduler, etc) that I could try to = achieve > "good" behavior? >=20 > 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. >=20 > --=20 > Andriy Gapon Are you out of your mind?! You are specifically asking for the absolute = worst possible behavior! If you have fifty tiny things to do on one side of the room and fifty = tiny things to do on the other side, do you cross the room after each = one? Of course not. That would be *ludicrous*. If you want/need strict alternation, feel free to code it. But it's the = maximally inefficient scheduler behavior, and it sure as hell had better = not be the default. DS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?MDEHLPKNGKAHNMBLJOLKCEGGMKAC.davids>