-=> Quoting Peter Fitzsimmons to Phil Crown <=-



 PF> Doing i/o to different devices, each in their own thread,  allows OS/2

 PF> to overlap i/o;  definitely worth the effort for any type of program.



Interesting.

 

 PC> Also by using a secondary thread you can adjust the priority.  In my app

 PC> the thread that reads the com port runs at PRTYC_TIMECRITICAL and all

 PC> the other threads run at PRTYC_REGULAR.



 PF> This may actually be counter productive;  by servicing the device

 PF> driver too often,  you will call DosRead() more often (then if your

 PF> thread was running at a lower priority).  The DosRead() calls will

 PF> transfer fewer bytes with each call (perhaps as low as 1 to 10 bytes).

 PF> Since the overhead of calling DosRead() is _huge_,  you want to call

 PF> it as few times as possible,  and get as many bytes back with each

 PF> call (this is why "Wait for something" read timeout
processing is so

 PF> cool).



I am using MODE_WAIT_READ_TIMEOUT (wait-for-something) now.  I've tried

all the modes, MODE_READ_TIMEOUT or MODE_NOWAIT_READ_TIMEOUT was also

interesting.  I had it set so that it would read an entire page of data,

and display it all at once *very* quickly!



There was a disadvantage to this that when typing characters to send it

took a second or two show up on the screen. I was wondering about

creating an alogrithm to dynamically change the read mode depending on

how many chars are in the buffer, or perhaps change it when I'm typing

keystrokes so that they will show up immediately, then when something is

received swith to a mode that will read as many bytes as possible in one

DosRead() call.



 PF> By lowering the priority,  and DosReading, say, 100+ bytes at a time

 PF> (and 10 times fewer DosRead calls),  your throughput will actually

 PF> increase (and your cpu load will lower drastically). 

 PF> I have written a lot of OS/2 comm software.  None of them use time

 PF> critical.  What I usually do is run all threads at "regular", and

 PF> allow an option to run at "foreground server" for taxed
systems;  for

 PF> the later,  however,  I raise the priority of all of the threads,  not

 PF> just the comm thread,  so that the balance I described above is

 PF> maintained.



I have also noticed that reading as many bytes as possible at one time

will lower the CPU load.



Phil Crown

pcrown{at}airmail.net

http://web2.airmail.net/pcrown/



--- Blue Wave/OS2 v2.30