Re: our friend the win32 system timer. - Mailing list pgsql-hackers-win32

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" <tgl@sss.pgh.pa.us>
To: "Merlin Moncure" <merlin.moncure@rcsonline.com>
Cc: <pgsql-hackers-win32@postgresql.org>
Sent: Tuesday, August 17, 2004 1:05 AM
Subject: Re: [pgsql-hackers-win32] our friend the win32 system timer.


> "Merlin Moncure" <merlin.moncure@rcsonline.com> 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 majordomo@postgresql.org so that your
>      message can get through to the mailing list cleanly
>