Using Timers

Applications frequently need to synchronize the execution of threads, to cause an event to occur after a specified interval, or to cause an event to occur at regular intervals. Timers are typically used to enable an application to pause before processing user input or to carry out a task at a given time.

OS/2 provides the following timer functions:

DosSleep suspends the execution of the calling thread, enabling other threads to run while the calling thread sleeps.
DosAsyncTimer starts a single-interval timer.
DosStartTimer starts a repeated-interval timer.
DosStopTimer stops a single-interval or repeated-interval timer.

The system also provides two functions, DosGetDateTime and DosSetDateTime, for getting and setting the system date and time.

The timers that are started by DosAsyncTimer and DosStartTimer are asynchronous timers; that is, the timers run independently of the calling thread, enabling the calling thread to perform other operations while the timer is running. When an asynchronous timer interval expires, the system notifies the application by posting an event semaphore.

Time intervals for DosAsyncTimer, DosStartTimer, and DosSleep are specified in milliseconds; however, it is important to recognize that the actual duration of the specified time interval will be affected by two factors:

First, the system clock keeps track of time in less precise units known as clock ticks. On most hardware, clock ticks occur approximately 32 times a second, so each tick interval lasts approximately 31.25 milliseconds. (To determine the duration of a clock tick on your computer, call DosQuerySysInfo, and examine the timer-interval field.)
Because clock ticks are less precise than millisecond values, any time interval that is specified in milliseconds will essentially be rounded up to the next clock tick.
Second, because OS/2 is a priority-based, multitasking operating system, there is no guarantee that a thread will resume execution immediately after the timer interval expires. If a higher priority process or thread is running, or if a hardware interrupt occurs, the timed thread blocks. (To minimize delays caused by preemptive scheduling, an application can dedicate a thread to managing time-critical tasks, and then raise that thread to a higher priority.)

These factors usually cause the timer interval to be longer than requested; however, it will generally be within a few clock ticks.

Timers for Presentation Manager applications are provided through the message queue. Therefore, a Presentation Manager application will not use the timer functions unless it performs some real-time control task.

Note: In the example code fragments that follow, error checking was left out to conserve space. Applications should always check the return code that the functions return. Control Program functions return an APIRET value. A return code of 0 indicates success. If a non-zero value is returned, an error occurred.

[Back: Asynchronous Timers]
[Next: Suspending the Current Thread]