Date: Sun, 23 Mar 1997 06:38:06 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@freefall.freebsd.org, mpp@freefall.freebsd.org Cc: cvs-all@freefall.freebsd.org, CVS-committers@freefall.freebsd.org, cvs-sys@freefall.freebsd.org Subject: Re: cvs commit: src/sys/nfs nfs_socket.c nfs_syscalls.c ... Message-ID: <199703221938.GAA09958@godzilla.zeta.org.au>
index | next in thread | raw e-mail
>> 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
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703221938.GAA09958>