From owner-cvs-sys  Sat Mar 22 11:41:16 1997
Return-Path: <owner-cvs-sys>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id LAA26862
          for cvs-sys-outgoing; Sat, 22 Mar 1997 11:41:16 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA26851;
          Sat, 22 Mar 1997 11:41:06 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id GAA09958; Sun, 23 Mar 1997 06:38:06 +1100
Date: Sun, 23 Mar 1997 06:38:06 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199703221938.GAA09958@godzilla.zeta.org.au>
To: bde@freefall.freebsd.org, mpp@freefall.freebsd.org
Subject: Re: cvs commit:  src/sys/nfs nfs_socket.c nfs_syscalls.c ...
Cc: cvs-all@freefall.freebsd.org, CVS-committers@freefall.freebsd.org,
        cvs-sys@freefall.freebsd.org
Sender: owner-cvs-sys@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>>   Fixed some invalid (non-atomic) accesses to `time', mostly ones of the
>>   form `tv = time'.  Use a new function gettime().  The current version
>>   just forces atomicicity without fixing precision or efficiency bugs.
>>   Simplified some related valid accesses by using the central function.
>
>Are you also going to fix the places where mono_time isn't accessed
>in an atomic manner?

Not for a while.  Most of the accesses are atomic enough:

In init_main.c:proc0_post(), ISTR that there was no problem because
the whole routine ran at splhigh(), but I think running at splhigh()
was a bug.

In uipc_socket2.c:sodropablereq(), msdosfs_vnode.c:deget() and
ufs_vnops.c:ufs_vinit() a random value is wanted, so non-atomicicity
and volatility are features.  In any case, the accesses are of the form
mono_time.tv_sec, so they are atomic on most machines (but not volatile).

There are lots of accesses to `time' that are only nonvolatile in practice
because they have the form time.tv_sec.  This is buggy in practice for
another reason: `time' lags the time given by microtime(&tv) by up to 10
msec, so times read using different methods may be inconsistent.  E.g.,
if `time' is {0, 990001}, then gettimeofday() may give {1, 0}.  If a file
is created within the next 9999 usec, then its modtime will be {0, 0},
which appears to be in the past.

I just noticed that `time' is still declared volatile when storage for it
is allocated in kern_clock.c.  It takes the -pedantic option to gcc to get
a warning about this :-(.

Bruce