From owner-freebsd-arch Wed Sep 27 19:26:33 2000 Delivered-To: freebsd-arch@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id 7C04B37B423 for ; Wed, 27 Sep 2000 19:26:27 -0700 (PDT) Received: from modemcable136.203-201-24.mtl.mc.videotron.ca ([24.201.203.136]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G1K00020S3Z9K@falla.videotron.net> for freebsd-arch@freebsd.org; Wed, 27 Sep 2000 22:26:23 -0400 (EDT) Date: Wed, 27 Sep 2000 22:30:11 -0400 (EDT) From: Bosko Milekic Subject: spinlocks and acquire pseudo-priority To: freebsd-arch@freebsd.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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? Thanks, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message