Date: Fri, 21 Aug 1998 09:35:51 -0500 From: Richard Wackerbarth <rkw@Dataplex.NET> To: Garance A Drosihn <drosih@rpi.edu> Cc: ac199@hwcn.org, Mike Smith <mike@smith.net.au>, joelh@gnu.org, hackers@FreeBSD.ORG Subject: Re: proposal to not change time_t Message-ID: <l03130300b203323fc2e9@[208.2.87.13]> In-Reply-To: <v04011707b202199e7df5@[128.113.24.147]> References: <Pine.BSF.3.96.980820014520.392H-100000@localhost> <199808192213.WAA00579@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 1:40 PM -0500 8/20/98, Garance A Drosihn wrote: >At 1:47 AM -0400 8/20/98, Tim Vanderhoek wrote: >>On Wed, 19 Aug 1998, Mike Smith wrote: >> >>> > by at least one unit (255ths, 1024ths, whatever), and then only >>> > resort to using duplicate times when it is forced to by benchmark >>> > programs that touch 1024 files per second just for kicks? >>> >>> It could simply be defeated by finding another pathalogical example. >>> Higher time resolution is the only way to fix it correctly. >> >> Sufficiently pathalogical examples defeat static resolutions (ie. >> any resolution that doesn't become finer as necessary). > >First, let me reiterate that I do believe it would be good to >have resolution better than 1 second... > >Having said that though, pathological situations make this pretty >much impossible to resolve, even if you have infinite precision >of when every file was last changed. Consider: > cc is compiling something.c, and reads in important.h > while cc is still compiling, some other process (maybe > running on a second CPU) modifies important.h > cc finishes, and writes out something.o > result: That something.o was *effectively* compiled with > the old important.h, even though the timestamps > of the two files would imply that something.o is > more recent than the new version of important.h > >So, even infinite resolution won't really solve all the >pathological cases. Completely solving them would get >rather tricky, and probably involves changes to the 'make' >command. You are correct that time precision, by itself, will never solve the multi-processor race condition that you describe. Rather than use the completion time of the operation, we should be using the starting time. This, coupled with the requirement, in "make" that the result always be "newer", by at least one tick, than each of its inputs will cause the results to be correct. Richard Wackerbarth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?l03130300b203323fc2e9>