Date: Thu, 1 Oct 1998 13:07:14 -0700 (PDT) From: Matthew Dillon <dillon@backplane.com> To: Guido van Rooij <guido@gvr.org>, Poul-Henning Kamp <phk@critter.freebsd.dk>, John Birrell <jb@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc_r/uthread uthread_gc.c Makefile.inc uthread_init.c uthread_find_thread.c uthread_kern.c uthread_create.c uthread_exit.c Message-ID: <199810012007.NAA05774@apollo.backplane.com> References: <199810011956.MAA05613@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
: The only thing you can assume as being atomic is a read or write, never
: a read-modify-write, because you never know what kind of optimizations
: (or lack thereof) the compiler will perform and also because some cpu's
: simply do not have a locked RMW capability.
oops, I meant a 'volatile read or write'. aka, to guarentee read or write
atomicy is to guarentee read or write ordering, as in the following
example. Any compiler which reorders the stores in this case
(or the loads in the read case) is broken.
volatile int a;
volatile int b;
code() {
a = 1;
b = 2;
}
-Matt
Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet
Communications & God knows what else.
<dillon@backplane.com> (Please include original email in any response)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810012007.NAA05774>