From owner-freebsd-current  Thu Sep  5 23:59:04 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id XAA01461
          for current-outgoing; Thu, 5 Sep 1996 23:59:04 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA01452
          for <current@freebsd.org>; Thu, 5 Sep 1996 23:59:01 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id QAA22321; Fri, 6 Sep 1996 16:50:49 +1000
Date: Fri, 6 Sep 1996 16:50:49 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199609060650.QAA22321@godzilla.zeta.org.au>
To: bde@zeta.org.au, tweten@frihet.com
Subject: Re: fixing accesses to volatile variable `time'
Cc: current@freebsd.org
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>>1. time.tv_sec is long, and accesses to longs are not guaranteed to 
>>   be atomic.  They happen to be atomic on i386's.
>
>To satisfy my curiosity, just who makes this "guarantee?"  Obviously, 

No one.  Accesses to ints and shorter types are just more likely to be
atomic because ints are supposed to be natural and efficient.

>access to a bit is inherently atomic, but I don't recall reading any C 
>language specification indicating that chars, shorts, or int accesses are 
>atomic whereas longs aren't.

The C standard only guarantees that accesses to sig_atomic_t's are atomic
(except in signal handlers, only write access is guaranteed - reading of
any non-local variable gives undefined behaviour!).

Bruce