Re: [Dev-C++] [Warning] Clock skew detected. Your build may beincomplete.

[Mac R. <re...@no...>]

At 12:11 AM 6/29/02 +0200, Hongli Lai wrote:
>On Fri, 2002-06-28 at 20:59, Mac Reiter wrote:
>> At 06:15 PM 6/28/02 +0200, Colin Laplace wrote:
>> Now the linker pass comes along and has some kind of problem, because it
>> can't tell if main.o is newer than main.cpp or not.  Does this sound like
>> the problem?  If so, either make needs to be modified to somehow use more
>> accurate timestamps (difficult, since it relies on file timestamps, which
>> are OS determined), or GCC needs to be modified so that if it completes
>> compilation in less than one second, it delays a second to let the
>> timestamps differ.  If this actually is the problem, it is only going to
>> get worse as machines get faster.
>> 
>
>Actually, GCC or the linker don't check on anything. Make does that.
>So make will have to be modified, not GCC.

I am aware of that.  But the problem *could* be fixed by GCC ensuring that
from the time it started until the time it wrote the result was at least
one second long.  It would NOT be the RIGHT place to fix it, but it WOULD
guarantee that the timestamps all differed.

The RIGHT place to fix it is in 'make', obviously, since it is 'make' that
is having timestamp problems.  Since 'make' cannot go to more accurate
timers (it must rely on file timestamps, which are OS specified), it could
use the "delay if I need to" method between each program invocation stage.
If it guaranteed that at least one second passed between each step, that
should fix most things.  It still wouldn't guarantee that the first step
was OK, since the file could have been saved, then make started, then GCC
run to completion all within one second.  To fix that, make would need to
perform the delay step *before* each invocation, not just *between* all
invocations -- that way it would delay before the first invocation,
allowing the clock to advance between the save and the running of GCC.

Oh, and while I'm on the subject of clocks -- keep in mind that staring at
a computer clock can keep it from moving.  In particular on DOS machines,
running a program that loops continuously asking for the time and
displaying it will cause the clock to lose several minutes per hour,
possibly more on faster machines.  A fast enough machine might be able to
stop it completely.  On DOS, reading the clock does lock out the update
interrupt, so if you read the clock enough, the update interrupt can't ever
get through.  This is the flip side to the problem I described earlier
about reading a clock that did *not* lock itself during read, which allowed
for having the value change while you were reading, leading to clocks
appearing to run backward and other atrocities.

In case you're wondering, the right (or at least better) solution (which
can only be implemented by hardware designers) is to double buffer (I
believe the hardware term is register, or latch, but I'm not sure) the
clock.  Allow the update interrupt to always be able to write into the
writable buffer.  Allow upper layers to always be able to read from the
readable buffer.  Whenever either buffer is unlocked (when either update
interrupt exits or upper layer read function exits), see if the other
buffer is also unlocked, and if it is, copy (latch) the value from the
writable buffer to the readable buffer.  Really fast readers could still
stall out the update process, but once the program went away, the clock
would properly update.  I suppose you could have a bit to signal that an
update is pending, so that you could block reader applications out until
you could get the latching from writable to readable done...

Oh well -- doesn't matter, since the PC hardware won't be changing any time
soon (at least in that regard).  Just passing on some painfully learned
knowledge about how clocks are not nearly as nice and simple as you would
think they are...
-
 _____________________________     /"\
 Mac Reiter                        \ /    ASCII Ribbon Campaign
 Nomadics, Inc.                     X     Against HTML Mail
 re...@no...               / \   (To join the campaign, simply use
                                          this in your signature.)