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>
index | next in thread | previous in thread | raw e-mail
> 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. > > -- > 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. DShelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?MDEHLPKNGKAHNMBLJOLKCEGGMKAC.davids>