Re: our friend the win32 system timer.

Accurate timers on Windows are a real problem. Unfortunately, performance 
counters do not solve it. They are meant to be used for relatively short 
time interval measurements, and cannot really be used to create a high 
resolution system timer which needs reliable and accurate periodic 
increments. But you can try the following:
Provide your own timer using a counter initialized with the current 
timestamp retrieved from Windows as you did up to now. Then register a 
peridioc multimedia timer via timeSetEvent() with 1 ms resolution. In the 
callback function, simply increase your timestamp by exactly this 1 ms 
(larger time quantums, e.g. 5 ms, are possible, but no smaller ones). Take 
your own manually maintained timestamp value as function result for now(). I 
used this approach some time ago and it worked very well. First I was afraid 
that this counter and the actual system time might run kind of 
asynchronously and therefore create a widening gap between this logical time 
and the actual time, but it turned out to run perfectly synchronous. I know 
this is not very elegant, by actually I do not know any alternative. MSDN 
does not cover this kind of problem either. I tried to use other time 
functions like GetSystemTimeAsFileTime() which theoretically can provide 100 
ns resolution (!), but it turned out to have the same 10 ms granularity you 
are struggling with right now.
Anyway, be aware that for multiprocessor access you need to lock the counter 
variable if it is larger then the platform bus width (e.g. 64 bit timestamp 
on 32 bit machines) because otherwise read and write access might take place 
as memory bus read/write cycles with possible interference in-between.
Hope this helps somehow...

Regards,
Christian.


----- Original Message ----- 
From: "Tom Lane" <[email protected]>
To: "Merlin Moncure" <[email protected]>
Cc: <[email protected]>
Sent: Tuesday, August 17, 2004 1:05 AM
Subject: Re: [pgsql-hackers-win32] our friend the win32 system timer.


> "Merlin Moncure" <[email protected]> writes:
>> This means that a table with a timestamp column defaulted to now() and a
>> unique constraint on that column will have a very high chance of
>> constraint violations.  This might happen when reading in values from a
>> script, and it works fine on Linux.
>
> Any application that assumes it will get unique results from now() is
> broken by definition.  The fact that it manages not to fail on some
> platforms doesn't make it less broken.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
>      subscribe-nomail command to [email protected] so that your
>      message can get through to the mailing list cleanly
> 



---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend