Date: Tue, 31 Oct 2000 13:10:34 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: freebsd-smp@FreeBSD.org Subject: Re: Reference count invariants in a fine-grained threaded environment Message-ID: <Pine.NEB.3.96L.1001031125750.58688y-100000@fledge.watson.org> In-Reply-To: <Pine.NEB.3.96L.1001031123647.58688x-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 31 Oct 2000, Robert Watson wrote: > Speaking of this issue: in a shared struct where some fields are constant > and others are not, false sharing can be a problem. I.e., if the memory > architecture defines locked memory access over a memory line that's 8 > bytes, but the compiler places two 32-bit variables in that line, with one > protected by a mutex and the other not. What should we assume for all > supported architectures, or is it better to cover the entire structure > with a mutex (in which case, must it be the same mutex as the reference > count in the object, given that the reference count and another variable > might be covered by the same locked operation?) So, just to put this concern into a little context: some older Alpha chips don't allow dereferencing pointers at char-level granularity, requiring a minimum retrieval size of (I forget exactly, but would guess 64 bits). If multiple char variables in a struct are packed adjacently, then read-write on these variables is non-atomic, and if two mutexes are used independently to protect two packed chars, then you still have races. Presumably solutions involve having the compiler not do that (no idea what it does by default -- probably packs for arrays, which are a seperate issue by themselves), either by default or by using qualifiers on variables in the struct, or requiring a single mutex to protect them all. All of these problems are solvable, we just need to have the solution defined somewhere (don't do that, compiler magic is safe to rely on, don't use multiple mutexes to protect one struct, or explicit compiler magic is required (volatile)). 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.1001031125750.58688y-100000>