Differences between AbtTimedWait and Delay

[cknittel]

Hi,

To wait for a number of seconds (say 5), I could use

Code: Select all

(Delay forSeconds: 5) wait.

or

Code: Select all

AbtTimedWait forSeconds: 5.

The effect seems to be the same, but the implementation of the wait differs. The Delay class uses a timer interrupt (primitive #installTimerReceiver:selector:), whereas AbtTimedWait seems to call

Code: Select all

useThreadMethod

   Sleep coroutineCallWith: waitInterval

("Sleep" being the Windows API function "<c: void 'kernel32.dll':Sleep uint32>").

The latter method seems a bit strange to me. Could you please comment on the reasoning behind the two implementations?

Thanks and best regards,
Christoph

[a3aan]

I don't know about the reasoning but the first just delays a single process in your image while the other processes are unaffected, and the other one seems to put the whole image to sleep. Different use cases, different implementations.

HTH,
Adriaan.

[cknittel]

No, the AbtTimedWait does not put the whole image to sleep (#callWith: would do so, but #coroutineCallWith: does not).

Just try

Code: Select all

[ AbtTimedWait forSeconds: 10 ] fork

to see.

Regards,
Christoph

[marten]

Reading the source code may give a hint ....

Code: Select all

wait
   "Block the current process for the duration of waitInterval.  Try
    to use threading to minimize overhead."

   self waitInterval == 0 ifFalse: [
      AbtThreadManager threadsSupported
         ifTrue: [self useThreadMethod]
         ifFalse: [self useRawSmalltalkMethod]]


[cknittel]

Hi Marten,

Yes, I saw that, but it just added to my confusion.

On Windows, AbtThreadManager threadsSupported is true, so the "thread method" (#coroutineCallWith:) is used. I am not sure if that minimizes overhead, but at least it seems to increase precision.

I just ran

Code: Select all

Time millisecondsToRun: [ (Delay forMilliseconds: 30) wait ].

Time millisecondsToRun: [ (AbtTimedWait forMilliseconds: 30) ].

and the former seems to actually run between 47 and 110 milliseconds on my system, the latter always 31-32.

So it would seem that AbtTimedWait should be used if precision is required, especially for short waits. Are there any drawbacks of using AbtTimedWait?

Regards,
Christoph

[marten]

Consider a large software system where you work with Delays - just to simulate the time and now think about having hundreds of threads in Smalltalk (which is ok) working with AbtTimedWait. Each one would then need an external thread - which becomes very cost intensive on all operating systems. Then the Delay structure would be much better.

I therefore think, that minimizing overhead is a "relative" statement. It minimizes the overhead because Smalltalk does not have to check the end of the delay regularly.

Another thing one could ask, how do both solutions react to time changes during their delaying time ...

Marten

[wembley]

You are correct -- AbtTimedWait was originally implemented to provide a more accurate timing mechanism than Delay. Remember Delay is driven off an interrupt which fires every 100ms (by default). This means that a delay interval can be off by that much. AbtTimedWait was created at a time when threading was not available on all platforms, thus the test for threadsSupported. The comment regarding 'minimizing overhead' relates to the difference between the threaded and non-threaded version of AbtTimedWait, not between AbtTimedWait and Delay.

[cknittel]

Thanks for the clarification!

Regards,
Christoph