Date: Tue, 31 Oct 2000 15:14:08 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: Alfred Perlstein <bright@wintelcom.net> Cc: freebsd-smp@FreeBSD.org Subject: Re: Reference count invariants in a fine-grained threaded environment Message-ID: <Pine.NEB.3.96L.1001031150244.58688G-100000@fledge.watson.org> In-Reply-To: <20001031115506.Y22110@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> Robert Watson's explanation on how he was going to handle atomic > ops with mutexes rather than discussing my proposed atomic_t (or > atomicref_t) made it pretty clear that either he has somehow missed > (happens to disagree with) my proposals. To be honest, I had forgotten about the atomic operation proposal and was relying only on primitives that we already had. When atomic operations were proposed in the follow-up message I acknowledged that they could be used, but that they didn't meet the needs of the piece of code I was working with. The reason I selected mutexes in the new jail code was the ancillary reason: the same mutex protects the consistency of the data structure the prison structures are linked into, which is a means by which a new reference can be gained. I.e., while atomic operations would work fine for crcopy(), the don't work in environments where new references don't have to be generated by inheritence. For example, in the new prison code, you can either get a reference to a prison by borrowing it from an existing reference, inheritting from an existing reference (i.e., increment the reference count), or by using prison_find() which walks the list of prison structures searching for a particular jailid. If you don't have a mutex protecting the increment there, you can get into a race condition. As I stated in my follow-up e-mail, I'm fine with atomic operations in locations where appropriate. I refuse to comment on the various means by which atomic operations might be implemented, as I am utterly unqualified to comment on that topic. :-) I would be happy with atomic operations in the general case as long as either (a) we provide an alternative that's easy to use for platforms that don't have atomic increment and decrement, or (b) we don't care about platforms without them. This is a moot point if there are no platforms not supporting the atomic operation requirements, but I am not qualified to make statements about that either. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1001031150244.58688G-100000>