From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@9fans.net
Subject: Re: [9fans] ilock funny?
From: "Russ Cox" <rsc@swtch.com>
Date: Thu, 29 May 2008 09:59:36 -0400
In-Reply-To: <c15da790f17dd290f2a12308293e124f@quanstro.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20080529135908.815F11E8C53@holo.morphisms.net>
Topicbox-Message-UUID: af58059e-ead3-11e9-9d60-3106f5b1d025

> i can't see how this could be unless on very first
> reference of the lock there is a race with the looser
> evaluateing !l->isilock before that processor can see
> the winner setting l->isilock to 1.
>
> if this diagnosis is correct, what is the proper fix?

take the test out.

this is my fault.  (ironically, i put it in while debugging
some of your code, years ago.)

change:

		/*
		 * Cannot also check l->pc and l->m here because
		 * they might just not be set yet, or the lock might
		 * even have been let go.
		 */
		if(!l->isilock){
			dumplockmem("ilock:", l);
			panic("corrupt ilock %p pc=%luX m=%p isilock=%d",
				l, l->pc, l->m, l->isilock);
		}

to

		/*
		 * Cannot also check l->pc, l->m, or l->isilock here
		 * because they might just not be set yet, or
		 * (for pc and m) the lock might have just been unlocked.
		 */

two out of three isn't bad.  ;-)

russ