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>
next in thread | raw e-mail | index | archive | help
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703221938.GAA09958>