Skip site navigation (1) Skip section navigation (2)

Re: our friend the win32 system timer.

From: "Christian Klemke" <Christian(dot)Klemke(at)t-online(dot)de>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,"Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>,"Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "pgsql-hackers-win32" <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: our friend the win32 system timer.
Date: 2004-08-17 09:41:21
Message-ID: 005d01c4843e$5ad60230$2401a8c0@NTBKCKLEMKE (view raw, whole thread or download thread mbox)
Lists: 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...


----- Original Message ----- 
From: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
Cc: <pgsql-hackers-win32(at)postgresql(dot)org>
Sent: Tuesday, August 17, 2004 1:05 AM
Subject: Re: [pgsql-hackers-win32] our friend the win32 system timer.

> "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)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(at)postgresql(dot)org so that your
>      message can get through to the mailing list cleanly

In response to

pgsql-hackers-win32 by date

Next:From: Andreas PflugDate: 2004-08-17 10:40:58
Subject: Re: [PATCHES] libpq build problem with <io.h>
Previous:From: Tom LaneDate: 2004-08-17 04:51:28
Subject: Re: libpq build problem with <io.h> on MS VC++

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group