From owner-freebsd-hackers Fri Aug 21 07:45:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA13921 for freebsd-hackers-outgoing; Fri, 21 Aug 1998 07:45:43 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA13916 for ; Fri, 21 Aug 1998 07:45:41 -0700 (PDT) (envelope-from rkw@Dataplex.NET) Received: from [208.2.87.13] (gw000-128.dataplex.net [208.2.87.13]) by shrimp.dataplex.net (8.9.1/8.9.1) with ESMTP id JAA04582; Fri, 21 Aug 1998 09:44:31 -0500 (CDT) (envelope-from rkw@dataplex.net) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: References: <199808192213.WAA00579@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Aug 1998 09:35:51 -0500 To: Garance A Drosihn From: Richard Wackerbarth Subject: Re: proposal to not change time_t Cc: ac199@hwcn.org, Mike Smith , joelh@gnu.org, hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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