Date: Thu, 19 Jun 2014 19:05:48 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Mateusz Guzik <mjguzik@gmail.com> Cc: Robert Watson <rwatson@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: capability races (was: Re: Seeing ENOTCAPABLE from write FDs in kqueue?) Message-ID: <CAJ-Vmon0WDyuSzd53L7uHNPtcoKTyiKTvAFRVdUq-Z=aBgq%2BWg@mail.gmail.com> In-Reply-To: <20140620010424.GA5830@dft-labs.eu> References: <CAJ-VmonJaqg=WV0eTxknOQr51E5qdhDU=MdoCywz-hwZ57jj6w@mail.gmail.com> <20140608220000.GA5030@dft-labs.eu> <20140608230059.GB5030@dft-labs.eu> <20140618203314.GB7157@dft-labs.eu> <20140620010424.GA5830@dft-labs.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
[snip] I'm increasingly wary of hand-rolled memory barrier / atomic using constructs like this. It's way, way too easy to shoot a foot off on an architecture that you don't have or know. So, if we're going down this rabbit hole further, I think we should first define all the places this stuff gets touched and try to come up with some behavioral description that we could try and link to some existing (non-patent-encumbered) no-lock based design pattern. So in your example, yes the pointer assignment is atomic, but there's no current guarantee that anything currently operating on that pointer has finished. That's what things like RCU address. It's cool that you've kept digging into this :-) -a
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmon0WDyuSzd53L7uHNPtcoKTyiKTvAFRVdUq-Z=aBgq%2BWg>