From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Wed, 14 May 2014 17:46:12 -0400
To: 9fans@9fans.net
Message-ID: <0e4fae9ce6a01f89f88bf1f6aead159e@ladd.quanstro.net>
In-Reply-To: <69df9a1401f0f33ca80a73b221d7758d@ladd.quanstro.net>
References: <ffbe73aa19ef921d30a236b5a3919060@ladd.quanstro.net>
	<CAOw7k5jUAoMvn1eXYB2iC2EBn_tEHLdGpnuQ5EDc=OAZaGCcFg@mail.gmail.com>
	<69df9a1401f0f33ca80a73b221d7758d@ladd.quanstro.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] ainc() 386/amd64 differences
Topicbox-Message-UUID: e66a7d50-ead8-11e9-9d60-3106f5b1d025

On Wed May 14 17:27:58 EDT 2014, quanstro@quanstro.net wrote:
> > int
> > incref(Ref *r)
> > {
> > int x;
> >
> > x = ainc(&r->ref);
> > if(x <= 0)
> > panic("incref pc=%#p", getcallerpc(&r));
> > return x;
> > }
>
> ah, yes.  i'd not remembered this nice implementation.
>
> then your ainc is guard-free?  and your Ref is struct Ref {int ref;}?
> also, did you decide that any reuse of the ref lock is already buggy and needs
> no further review?  that's the bit i got bogged down on.

i've rebooted my kernel with this change, and it appears to be solid.
still a bit concerned about additional consistency forced by the prior
incref.

- erik