On Fri, 18 Apr 2008 01:38:20 -0700, }{ <sn****@groups.comwrote:
I have an app that reads a character string on com 1, waits for a signal
(any ascii char) on com 2, then outputs the string on com 2.
I seem to have a problem with the timing. It just so happens that the
signal
from com2 arrives at the same time as the next string for com1.
Do the com ports run in sepaerate threads by default, or should I be
doing
something in code to make this happen.
The "com ports" themselves are handled by the OS. Whether they run in
separate threads or not is immaterial and out of the scope of your
application.
Now, as far as the code in your application that reads the COM ports, .NET
does not introduce new threads to your application's code without your
say-so. If you have written your application as a single-threaded
application, then all of your i/o will be handled in a single-thread.
With most of the i/o classes, there are asynchronous methods that allow
for multi-threaded processing of the i/o. You don't create a thread
explicitly using these methods, but the framework manages special i/o
worker threads that are used whenever some i/o occurs. Your own code
winds up being executed on one or more of these threads, and in that way
the i/o can be dealt with in a multi-threaded way.
I haven't use the SerialPort class (I assume that's what you're using),
and my recollection is that it has a slightly different API that most of
the other i/o classes. So I can't offer specific advice about how best to
approach the multi-threaded issue. However, I can see that the SerialPort
class does have a BaseStream property from which you can get a Stream
instance, and for sure the Stream class provides the asynchronous API I
mentioned above.
That's how I would approach it initially. If for some reason that didn't
work out, then I might look into creating my own threads to deal with the
different ports. But one way or the other, you need to tell .NET via the
code you write that you want a multi-threaded solution, if indeed you do.
Pete
