What is the best way to program a delay in Delphi?
Taking your questions in turn:
- Is this a proper way to program a delay?
Yes (but also "no" - see below).
The 'proper way' varies according to the specific requirements and the problem being solved. There is no Universal Truth on this and anyone telling you otherwise is trying to sell you something (to paraphrase).
In some cases waiting on an event is the proper delay mechanism. In other cases not.
- If the answer is yes, then why is this better than a call to Sleep()?
See above: The answer is yes. However, this second question simply does not make sense since it assumes that Sleep() is always and by necessity never the proper way which, as is explained in the answer to #1 above, is not necessarily the case.
Sleep() may not be the best or most appropriate way to program a delay in all scenarios, but there are scenarios where it is the most practical and has no significant drawbacks.
Why People Avoid Sleep()ing
Sleep() is a potential problem precisely because it is an unconditional delay that cannot be interrupted until a specific time period has elapsed. Alternative delay mechanisms typically achieve precisely the same thing with the only difference being that there exists some alternative mechanism to resume execution, other than the mere passage of time.
Waiting for an event delays until the event occurs (or is destroyed) or a specific period of time has passed.
Waiting for an mutex causes a delay until the mutex is acquired (or is destroyed) or a specific period of time has passed.
etc.
In other words: Whilst some delay mechanisms are interruptible. Sleep() is not. But if you get the other mechanisms wrong there is still the potential to introduce significant problems and often in a way that can be far more difficult to identify.
Problems With Event.WaitFor() In This Case
The prototype in the question highlights a potential problem of using any mechanism that suspends execution of your code if the rest of that code is not implemented in a way that is compatible with that particular approach:
Form1.Timer1.Enabled := true;
Form1.EventManager.ResetEvent;
Form1.EventManager.WaitFor(INFINITE);
If this code is executed in the main thread then Timer1 will never happen.
The prototype in the question executes this in a thread, so this particular problem doesn't arise, but it is worth exploring the potential since the prototype does introduce a different problem as a result of the involvement of this thread.
By specifying an INFINITE wait timeout on your WaitFor() on the event, you suspend execution of the thread until that event occurs. The TTimer component uses the windows message based timer mechanism, in which a WM_TIMER message is supplied to your message queue when the timer has elapsed. For the WM_TIMER message to occur, your application must be processing its message queue.
Windows timers can also be created which will provide a callback on another thread, which might be a more appropriate approach in this (admittedly artificial) case. However this is not a capability offered by the VCL TTimer component (as of XE4 at least, and I note you are using XE2).
Problem #1
As noted above, WM_TIMER messages rely on your application processing its message queue. You have specified a 2 second timer but if your application process is busy doing other work it could potentially take far longer than 2 seconds for that message to be processed.
Worth mentioning here is that Sleep() is also subject to some inaccuracy - it ensures that a thread is suspended for at least the specified period of time, it does not guarantee exactly the specified delay.
Problem #2
The prototype contrives a mechanism to delay for 2 seconds using a timer and an event to achieve almost exactly the same result that could have been achieved with a simple call to Sleep().
The only difference between this and a simple Sleep() call is that your thread will also resume if the event it is waiting for is destroyed.
However, in a real-world situation where some further processing follows the delay, this is itself a potentially significant problem if not correctly handled. In the prototype this eventuality is not catered for at all. Even in this simple case it is most likely that if the event has been destroyed then so too has the Timer1 that the thread attempts to disable. An Access Violation is likely to occur in the thread as a result when it attempts to disable that timer.
Caveat Developor
Dogmatically avoiding the use of Sleep() is no substitute for properly understanding all thread synchronization mechanisms (of which delays are just one) and the way in which the operating system itself works, in order that the correct technique may be deployed as each occasion demands.
In fact, in the case of your prototype, Sleep() provides arguably the "better" solution (if reliability is the key metric) since the simplicity of that technique ensures that your code will resume after 2 seconds without falling into the pitfalls that await the unwary with over-complicated (with respect to the problem at hand) techniques.
Having said that, this prototype is clearly a contrived example.
In my experience there are very few practical situations where Sleep() is the optimal solution, though it is often the simplest least error prone. But I would never say never.
Scenario: You want to perform some consecutive actions with a certain delay between them.
Is this a proper way to program a delay?
I would say there are better ways, see below.
If the answer is yes, then why is this better than a call to Sleep()?
Sleeping in the main thread is a bad idea: remember, the windows paradigm is event driven, i.e do your task based on an action and then let the system handle what happens next. Sleeping in a thread is also bad, since you can stall important messages from the system (in case of shutdown, etc).
Your options are:
Handle your actions from a timer in the main thread like a state machine. Keep track of the state and just execute the action which represents this particular state when the timer event fires. This works for code that finishes in a short time for each timer event.
Put the line of actions in a thread. Use an event timeout as a timer to avoid freezing the thread with sleep calls. Often these types of actions are I/O bound, where you call functions with built-in timeout. In those cases the timeout number serves as a natural delay. This is how all my communication libraries are built.
Example of the latter alternative:
procedure StartActions(const ShutdownEvent: TSimpleEvent);
begin
TThread.CreateAnonymousThread(
procedure
var
waitResult: TWaitResult;
i: Integer;
begin
i := 0;
repeat
if not Assigned(ShutdownEvent) then
break;
waitResult := ShutdownEvent.WaitFor(2000);
if (waitResult = wrTimeOut) then
begin
// Do your stuff
// case i of
// 0: ;
// 1: ;
// end;
Inc(i);
if (i = 10) then
break;
end
else
break; // Abort actions if process shutdown
until Application.Terminated;
end
).Start;
end;
Call it:
var
SE: TSimpleEvent;
...
SE := TSimpleEvent.Create(Nil,False,False,'');
StartActions(SE);
And to abort the actions (in case of program shutdown or manual abort):
SE.SetEvent;
...
FreeAndNil(SE);
This will create an anonymous thread, where the timing is driven by a TSimpleEvent. When the line of actions are ready, the thread will be self destroyed. The "global" event object can be used to abort the actions manually or during program shutdown.