Date: Fri, 2 Oct 1998 13:02:16 +1000 From: Bruce Evans <bde@zeta.org.au> To: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, dillon@backplane.com, guido@gvr.org, jb@FreeBSD.ORG, phk@critter.freebsd.dk 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: <199810020302.NAA10722@godzilla.zeta.org.au>
next 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
You meant a `volatile sig_atomic_t read or write'. Longs can be larger
than the largest memory access size. Shorts and chars can be smaller than
the smallest memory access size.
> 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;
> }
`volatile' is not necessary here in practice, since Standard C requires
stores to act as if they are complete at sequence points, and compilers
attempt to implement Normal C which requires everything to work Normally
in signal handlers.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810020302.NAA10722>