Date: Thu, 2 Nov 2000 00:03:42 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: Robert Watson <rwatson@freebsd.org> Cc: freebsd-smp@freebsd.org Subject: Re: Reference count invariants in a fine-grained threaded environment Message-ID: <Pine.BSF.4.21.0011020000400.256-100000@salmon.nlsystems.com> In-Reply-To: <Pine.NEB.3.96L.1001031125750.58688y-100000@fledge.watson.org>
index | next in thread | previous in thread | raw e-mail
On Tue, 31 Oct 2000, Robert Watson wrote: > 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). 32 bits. > If > multiple char variables in a struct are packed adjacently, then read-write > on these variables is non-atomic, It can still be atomic (we have 16 and 8 bit variants of all the atomic ops). Its a bit slower though and its based on atomic access to the surrounding qword so it can't work for memory mapped devices. > 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)). The best solution is use 32 or 64 bits for performance. Smaller types are usable but cost a bit more. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the messagehelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0011020000400.256-100000>