From owner-cvs-all Thu Oct 1 20:02:48 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA17546 for cvs-all-outgoing; Thu, 1 Oct 1998 20:02:48 -0700 (PDT) (envelope-from owner-cvs-all) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA17541; Thu, 1 Oct 1998 20:02:40 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id NAA10722; Fri, 2 Oct 1998 13:02:16 +1000 Date: Fri, 2 Oct 1998 13:02:16 +1000 From: Bruce Evans Message-Id: <199810020302.NAA10722@godzilla.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 Sender: owner-cvs-all@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >: 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