David Etheredge wrote in a message to Peter Fitzsimmons:

 PF> What's a tic counter?  (Just kidding).  Under OS/2,  
 PF> you need not stoop to such gimicks.  There are many 
 PF> ways to pass time (DosSleep), be woken up periodically 
 PF> (DosStartTimer),  or to synchronize with other 
 PF> threads/programs (DosWaitEventSem).   The APIs shown in 
 PF> brackets are just a starting point...

 DE> OK, don't want to sleep ... have too much to do while I am
 DE> waiting. Just want to know immediatly when the time has
 DE> elapsed. I know that I can start another thread and put this
 DE> one to sleep, but ... I need to respond immediatly to the
 DE> wakeup call and the child thread must stop while I am
 DE> processing. 

"Immediately" is a rather vague term in this context.  The OS/2
scheduler has a granularity of about 32 ms.  This means that a task switch
at application level has a mean latency of half that, or about 16 ms.  You
can force the maximum latency to be quite low with something like
"TIMESLICE=32,32" in CONFIG.SYS, but then this will apply to your
threads also.

The trick to doing what you want is to run the thread at time-critical or
fixed-high priority and have it blocked in one of the ways Peter mentions. 
When the thread is made ready, it will very likely be the next thread run
by the scheduler because of its high priority.

Stopping the other thread can be done a number of ways.  The easiest is
probably to use DosEnterCritSec() and DosExitCritSec().  Between these two
calls, no other thread in the process will be scheduled to run.  However,
declaring a critical section is a fairly drastic action, and you may find
that you can get away with simply serializing a resource on a local
(unnamed) semaphore,  which is also much faster.

 DE> I understand that detail can be important in resolving
 DE> something like this, but there are disclosure limitations.

What you are doing is very similar to what a lot of OS/2 programmers do.

 DE> My objective is process control. A certain amount of time
 DE> error +/- 10 msec is acceptable. The most likely resolution
 DE> of this problem is that I will have to write a device
 DE> driver. While this is OK, and I have written several for
 DE> OS-9, I would rather that the driving process be contained
 DE> within the main program.  

If you need to respond to IRQs, then you must use a device driver.  If you
need to respond with appreciably less than 16 ms mean latency, then you
must use a device driver.

 DE> The main concern here is to drive a specialized serial port
 DE> which is driving a radio transmitter for a telemetry system.
 DE> Before transmission of the data, the radio must be keyed, a
 DE> wait for CTS, and then a minimum and  a maximum delay before
 DE> transmission begins and a maximum key up time. There is also
 DE> a keyup hold after transmission and several other timers and
 DE> inputs that must be watched. These times range from 20 msec
 DE> to 500 msec and may overlap.

The main question is whether your specialized serial port generates IRQs. 
If so, you will have no choice but to write a device driver.
 
-- Mike


---