Simultaneous (Atomic) Reading of Multiple Time Macros

[dpryan]

Is there a chance of obtaining the wrong time by using time macros?

For example, say I read the time like this:

$time = @HOUR+(@MIN/60)

Suppose the current time is approximately 1:59am, but the clock is in the process of ticking over to 2am.

The @HOUR macro returns 1, but then the clock ticks over and the @MIN macro returns 0. So that gives us a time of 1am instead of ~2am (1 hour too early).

Alternatively, if the @MIN macro is read first, it could return 59. Then as the clock ticks over the @HOUR macro reads 2. So that gives us 2:59am instead of ~2am (1 hour too late).

Is there any way to read the two macros at the same time?

[BrewManNH]

Autoit is single threaded, you're only going to be able to read one at a time. The scenario you posed is theoretically possible, but the likelyhood of it happening are very very small.

[dpryan]

Okay, thanks. I guess the safer thing to do is pull a single time "object" (for example _NowTime) and then calculate the $hours+$min/60 from that.

[AdmiralAlkex]

How is _NowTime() a single "object"??

Func _NowTime($sType = 3)
    If $sType < 3 Or $sType > 5 Then $sType = 3
    Return (_DateTimeFormat(@YEAR & "/" & @MON & "/" & @MDAY & " " & @HOUR & ":" & @MIN & ":" & @SEC, $sType))
EndFunc   ;==>_NowTime

It has exactly the same "problem".

[dpryan]

Haha. You're right. I didn't check the source code.

Here you go...

Based on: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724338%28v=vs.85%29.aspx

MsgBox(0,"Time",_GetLocalTime())
Func _GetLocalTime()
    Local $tSystemTime = DllStructCreate("WORD wYear;WORD wMonth;WORD wDayOfWeek;WORD wDay;WORD wHour;WORD wMin;WORD wSecond;WORD wMilliseconds")
    DllCall('kernel32.dll', 'none', 'GetLocalTime','ptr', DllStructGetPtr($tSystemTime))
    If (@error) Then
        Return SetError(1, 0, 0)
    EndIf
   $hour = DllStructGetData($tSystemTime,"wHour")
   $min = DllStructGetData($tSystemTime,"wMin")
   $sec = DllStructGetData($tSystemTime,"wSecond")
   $time = $hour+$min/60+$sec/3600
   Return $time
EndFunc

Edited December 12, 2011 by dpryan

[BrewManNH]

You're still going to have the same "problem" as it takes time to process those commands after you do the DLLCall, so theoretically it will still happen. As I said before I think the likelyhood of it happening is very small, but even with your code, the issue still exists.

[jchd]

It raises a real question with AFAIK no direct answer. The only way I see is to grab a Windows timestamp (that is an atomic operation) and convert to UTC or local time then dissect the HMS part, just as dpryan did.

@BrewMaNH,

No. There is no such problem with this code, since the timestamp is sampled only once. That it takes several instructions to process properly is irrelevant and won't change the (consistent) content of the structure. The returned values may have some shift (albeit very small) from the timestamp, but it will be consistent.

This might give the substance for a ticket as the current set of macros actually has a consistency problem (when used together to form YMD HMS or part of it).

Edited December 12, 2011 by jchd

[water]

Or you could check for the dangerous time and simply wait for 1 or 2 seconds

If @Min = 59 and @sec > 58 Then Sleep((60 - @Sec)*1000)

[BrewManNH]

@BrewMaNH,

No. There is no such problem with this code, since the timestamp is sampled only once. That it takes several instructions to process properly is irrelevant and won't change the (consistent) content of the structure. The returned values may have some shift (albeit very small) from the timestamp, but it will be consistent.

I see that now that you mention it, I wasn't thinking about the read once at the time.

[dpryan]

@water: I like your idea of a workaround (for those that don't want to use the dll call method), but sometimes sleeping for several seconds isn't acceptable. I think better way of doing this would be to get @HOUR and @MIN and then @HOUR again and see if @HOUR changed. If so, get @MIN again.

$hour = @HOUR
$min = @MIN
If ($hour <> @HOUR) Then
    $hour = @HOUR
    $min = @MIN
EndIf

@BrewManNM: You say the likelihood is very very small, but what is the probability of it happening? Say I'm using this to create an alarm clock. I'm checking the time in a small loop and when I reach a certain time, I set off the alarm. I don't want to wake up an hour early or an hour late.

So say I'm sampling the time in a 20ms loop. That means that we will take a time measurement within 20ms of the clock ticking over at the critical moment. I have no idea how many instructions it takes to get the @HOUR or @MIN macros. Let's make something up and say there are 40 instructions between. If we have a 2 GHz processor, then I think the probability is somewhere in the range 40 instructions divided by (20ms * 2Ghz) = 1 in a million chance.

Does that make sense? Of course, this is a very simplistic view with nothing else going on in the system. I don't know a lot about operating systems, but I think the scheduling of different processes and other operating system tasks might make it more likely that this problem happens. Also, I think it probably takes way more than 40 instructions to get the time in AutoIt, but I was trying to be conservative on the estimate.

Edited December 13, 2011 by dpryan

[BrewManNH]

If you want the alarm to go off at, for example 6:15AM. If you monitor the time such that if the @HOUR is >5 and @Hour < 7 and the @MIN is >=15 I don't see how that would be a problem. If you want it to go off at exactly 6:15 and never 6:16 or higher, then you will need to make sure you're checking the time in a tight enough loop that it checks it in less than 1 minute.