Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 Sep 2000 22:30:11 -0400 (EDT)
From:      Bosko Milekic <bmilekic@technokratis.com>
To:        freebsd-arch@freebsd.org
Subject:   spinlocks and acquire pseudo-priority
Message-ID:  <Pine.BSF.4.21.0009272218510.3246-100000@jehovah.technokratis.com>

next in thread | raw e-mail | index | archive | help

  	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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0009272218510.3246-100000>