Mike Bilow wrote in a message to Peter Fitzsimmons:

 MB> On each interrupt, we get an array containing 400
 MB> 16-bit elements, and we are expected to sum this array
 MB> element by element into an array containing 400 32-bit
 MB> elements.  That is,  

 MB>       process_interrupt() {

 MB>          static long sumarray[400];
 MB>          int i = 0;
 MB>          short _far *srcarray = MK_FP(0xD000,0x0000);

 MB>          while(i < 400)
 MB>             sumarray[i++] = *srcarray++;

 MB>          call_EOI()
 MB>       }
You should do this in a different way. Have the interrupt-handle copy
incoming data to a FIFO-buffer using a block-move. This should take less
than 1/10th millisecond per interrupt. This FIFO is rather straight forward
to implement for a good programmer. (There are many making 'little'
mistakes and producing worthless code.) You'll want to post a semafore when
the buffer has more than a certain amount of buffered data (say 4 blocks),
so you can signal your post-processor when there's work to do. Posting this
semafore on each transition from empty -> not empty is not a good idea,
since in normal circumstances the post-processing process is
blocked/unblocked on each interrupt, increasing overhead.

Provided that you have a large enough buffer, you'll be able to relax the
processing requirements for the post-processing using this buffer scheme.
Your post-processing process should bump up the priority of it's
calculation thread when the buffer becomes too full. The starting priority
of the calculation thread should be higher than that of normal
applications, so it will get enough processor time. If you start at a too
low priority, your process might only bump up it's priority *after* data
loss has already occurred.

The cool PM interface has to run in another thread or (if you're concerned
about security and fault-tolerance) in another process than the
calculation. The PM interface can get calculated data from the calculation
thread and run using normal priority itself.

Advantages of this approach:
 + Device driver writing and debugging is easier this way.
 + Less time-constraints on the calculation part.
 + Due to different priorities this real-time data-acquisition can
   be mixed with normal, inter-active use of the computer
 + Better performance, since the calculation thread can be pre-empted
 + Crash in user interface won't affect data-acquisition or calculation
 + Seperation of hardware-dependant, calculation-dependant and user-interface
   dependant code increases maintainability and portability.

I think OS/2 is very well suited for most real-time applications. Most
real-time app's can be splitted in a small time-critical part and a large
part that isn't really time-critical. Even when OS/2 won't be able to
handle the time-critical part using a device driver, it might be best after
all to add some extra hardware for buffering/controlling. 

Groetjes, Geert 
--- timEd/2 1.01+