From owner-freebsd-hackers Fri Aug 21 11:11:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA10490 for freebsd-hackers-outgoing; Fri, 21 Aug 1998 11:11:39 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from pau-amma.whistle.com (s205m64.whistle.com [207.76.205.64]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA10452 for ; Fri, 21 Aug 1998 11:11:31 -0700 (PDT) (envelope-from dhw@whistle.com) Received: (from dhw@localhost) by pau-amma.whistle.com (8.8.8/8.8.7) id LAA05293; Fri, 21 Aug 1998 11:10:23 -0700 (PDT) (envelope-from dhw) Date: Fri, 21 Aug 1998 11:10:23 -0700 (PDT) From: David Wolfskill Message-Id: <199808211810.LAA05293@pau-amma.whistle.com> To: freebsd-hackers@FreeBSD.ORG, rkw@Dataplex.NET Subject: Re: proposal to not change time_t In-Reply-To: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Date: Fri, 21 Aug 1998 09:35:51 -0500 >From: Richard Wackerbarth >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. I would expect that if you're concerned with timestamps generated by multi-processing systems, that it might be worth considering using a CPU number as the last few bits of the timestamp -- beyond the accuracy of anything "real" -- as a tie-breaker. As I recall, this is the technique IBM used on the s/3x0 "store clock" instruction.... david -- David Wolfskill UNIX System Administrator dhw@whistle.com voice: (650) 577-7158 pager: (650) 371-4621 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message