Date: Wed, 27 Sep 2000 23:05:39 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Bosko Milekic <bmilekic@technokratis.com> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: spinlocks and acquire pseudo-priority Message-ID: <20000927230538.I7553@fw.wintelcom.net> In-Reply-To: <Pine.BSF.4.21.0009272218510.3246-100000@jehovah.technokratis.com>; from bmilekic@technokratis.com on Wed, Sep 27, 2000 at 10:30:11PM -0400 References: <Pine.BSF.4.21.0009272218510.3246-100000@jehovah.technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Bosko Milekic <bmilekic@technokratis.com> [000927 19:26] wrote: > > I cannot quantify how likely the following is... but logically, it > should be more probable when there are more CPUs (at LEAST 3). > > Say a thread on processor 1 (A) grabs mutex Y, which happens to be a > spin-only type mutex. > > Say thread on processor 2 (B) attempts to grab mutex Y, but fails and > starts spinnnig in mtx_enter_hard(). > > Now say thread on processor 3 (C) attempts to grab mutex Y and makes > it to mtx_enter() -- at this very instant before C is about to try it the > "easy way" and do its cmpxchgl, A releases mutex Y. Now B is still > spinning; in fact, B is in mtx_enter_hard in the while() loop, it had > just checked whether the lock was still owned, and it was, so it's just > iterating again and incrementing the loop index variable. Before B goes > to the top of the loop and hits the comparison statement again (to see > whether Y is still owned), C does its cmpxchgl and grabs the lock easily, > without any issues whatsoever. B continues to spin and eventually the > loop index reaches the "tolerated" values and there's a panic(). > > Please also note that even if B hits the top of the while loop and > decides that the mutex is no longer owned, so it hits the top of the > infinite loop and tries to grab it again, just before it grabs it, it > could already be had by C. This isn't TOO much of a problem, because the > probability is low, but grows with the number of processors. The problem > I see is that the index i is never reset to zero and may eventually hit > the tolerated values and trigger a panic. > > Is there something I'm leaving out/forgetting? It seems like a possibility, however a spinlock being that contested is most likely a problem and needs to be fixed. It may be a good idea to examine the lock right before panicing to see if the lock state has changed. It may also be a good idea to alternate between a hard spin and a DELAY loop rather then backoff so much. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000927230538.I7553>