Date: Tue, 03 May 2005 22:26:11 -0700 From: Tim Kientzle <kientzle@freebsd.org> To: John Giacomoni <John.Giacomoni@colorado.edu> Cc: freebsd-hackers@freebsd.org Subject: Re: what goes wrong with barrier free atomic_load/store? Message-ID: <42785CF3.20009@freebsd.org> In-Reply-To: <200504261456.52070.jhb@FreeBSD.org> References: <adbc63802b6da49e587f294644f41a75@colorado.edu> <200504261456.52070.jhb@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
> On Wednesday 20 April 2005 04:39 pm, John Giacomoni wrote:
>
>>can someone give me an example of a situation where one needs to use
>>memory barriers to ensure "correctness" when doing writes as above?
One basic example:
struct foo *p = malloc(sizeof(struct foo)); // Step 1
p->bar = 0; // Step 2
atomic(global_p = p); // Step 3
This is a pretty common idiom: Allocate a new
data structure, initialize it, then assign the pointer
to a shared global value so that the fully-initialized
structure becomes visible all at once.
Many people miss an important detail:
A barrier is needed just before the
final pointer assignment. Otherwise, the
pointer might reach shared memory (Step 3) before
the initialization in Step 2 happens.
(This can happen because of compiler reordering
or processor write caching.)
Variations of this plagued the early attempts
to correctly define Java's threading primitives.
(It was possible to crash a lot of early JVMs
by creating new objects in one thread and
accessing them in another; every now and then
the accessing thread would see an uninitialized
vtable and crash the entire JVM.)
Tim Kientzle
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42785CF3.20009>