From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <1be4fa0d195c4b6021ba96e7ef467654@quanstro.net>
To: 9fans@9fans.net
From: erik quanstrom <quanstro@quanstro.net>
Date: Thu, 29 May 2008 10:01:28 -0400
In-Reply-To: <599f06db0805290640r7d8b7f8ajc413748a22508eac@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] ilock funny?
Topicbox-Message-UUID: af6094ac-ead3-11e9-9d60-3106f5b1d025

the code i typed in out of haste turns out to be exactly the same
as the code that had this problem, modulo names.

> isilock is a variable set by the lock to tainted as ilock instead of lock.
> Having isilock=1 onlys happen After the lock has been acquired by someone.
> The lock is checked with a tas() which I assume works because everything
> is based on it.

isilock is tested in the branch not holding the ilock.  therefore a winning
cpu can be executing the acquire branch and any number of loosing cpus can be
executing the body of the if statement concurrently.  where is the timing
guarentee that if this happens, the winning cpu executes l->isilock = 1
and the cacheline holding l->isilock has been flushed to the loosing cpu
before the !l->isilock test has been run?

i don't think that one needs to invoke any of the spectacularly odd things
that happen on modern pcs to explain this.  (for example, seperate cores
running at different frequencies.  or, my personal favorite, smm interrupting
things for a couple hundred ms.)

> My guess is that you have the lock uninitialized (key is not what it should be),
> so key has a bogus value and that is where your problems start.
> Zeroing the lock before using it should do the trick.

the lock is in the bss.  it has been zeroed by the linker.  in any event,
i don't think an uninitialized lock explains the behavior.  all we
need is good old-fashioned concurrency.

- erik