Re: our friend the win32 system timer. - Mailing list pgsql-hackers-win32
From | Christian Klemke |
---|---|
Subject | Re: our friend the win32 system timer. |
Date | |
Msg-id | 005d01c4843e$5ad60230$2401a8c0@NTBKCKLEMKE Whole thread Raw |
In response to | our friend the win32 system timer. ("Merlin Moncure" <merlin.moncure@rcsonline.com>) |
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 >
pgsql-hackers-win32 by date: