In fact, for the moment, I've just develop in C++ where I start a
thread with a high priority to read data on the serial port.
When some data is readen, I call a callback. As I know that my thread
priority is higher than main thread priority, I'm sure that all GUI
actions don't have impact on serial communication.
First, you should not be changing thread priorities without a really
good reason. And I don't think that handling serial i/o is a good
reason. Have you seen any indication of a performance issue without
changing the thread priority? Have you even written any .NET i/o code
yet?
Second, changing the thread priority does not ensure "that all GUI
actions don't have impact on serial communication". The Windows thread
scheduler will not preempt a thread that's already running even if a
higher priority thread becomes runnable. So, if data comes in on the
serial port while the GUI thread is already executing, it is
theoretically possible that that data will simply have to wait until
the GUI thread is done with its timeslice.
Also, if a higher priority thread is hogging the CPU, lower priority
threads eventually get a priority boost allowing them to run.
So, if it is possible at all for the GUI thread to interfere with the
serial i/o (which seems unlikely to me, but for the sake of
argument...), raising the thread priority for the serial i/o is not
guaranteed to eliminate that. If it were possible, raising the thread
priority could improve the situation, but it can't fix it completely.
But it's very unlikely that you need to change the thread priority
anyway. The serial i/o is (or at least should be) buffered, and
there's no reason at all that your serial i/o should not be able to be
processed frequently enough to keep up with the i/o rate even when
running at the normal thread priority.
In .NET technology, I don't know what the serial port priority is.
The serial port doesn't have a priority. A thread handling serial i/o
may have a priority, and you could easily find this out by using the
Thread class to check the current priority when handling serial i/o in
..NET. My guess is that it's normal priority, because there shouldn't
be any need to use anything different.
The serial port sends an event, then a delegate is called, but WHEN ?
I don't know the exact implementation of the .NET serial i/o class, but
I'd say there's a pretty good chance that it uses i/o completion ports.
Whether it's using IOCP or not, it's likely that some thread waiting
on the i/o is made runnable by the arrival of data, and will be
scheduled normally according to its position in the round-robin order
of runnable threads. When that thread is run, that would be when the
delegate is called.
By calling the delegate, just as any delegate would be called. As you
suggested in your original post, a delegate is very much like a
function pointer. It's basically the .NET equivalent to one, and when
code calls a delegate it's calling it directly from somewhere.
Now, some delegates are called via the Windows event queue (for
example, delegates passed to Control.Invoke()), so in that sense
sometimes they are like "an event mechanism". But that's not really
something inherent in delegates themselves; it's part of the
Control.Invoke() mechanism, or similar situations.
I'm not sure that for example if a user clicks every seconds on a
button, if the serial data reception won't be blocked.
Have you tried it? As long as you don't do anything bad in your GUI
code, it will work fine. By "bad", mostly I mean that as long as you
don't perform any time-consuming operations in the GUI code, there's no
chance of a problem. Even if you do perform time-consuming operations
in the GUI code, I suspect that the likelihood of a problem is very
low. The i/o won't get handled as often, but it's unusual for an i/o
thread to consume its entire timeslice (assuming all it's doing is
i/o), so it's likely the net throughput will still be the same, just in
larger bursts.
In fact, in .NET, everything is managed by the framework. So we don't
know what the impact is on the real time aspect.
There is no "real time" in Windows. Windows isn't a real-time OS, and
boosting thread priority in an attempt to make it one isn't going to
work.
What you should do is use the asynchronous methods on the serial class
that you've seen (start with "Begin..." and "End..."). Assuming the
serial class uses IOCP, it's not true that there's a thread dedicated
to a specific call to a "Begin..." method. Instead, a pool of threads
will be waiting to dequeue i/o completions. Windows will manage these
efficiently to ensure that a given thread continues to run in its
timeslice as long as there's some i/o that's completed and ready to
process.
You should not mess with thread priority. For a serial port
especially, the normal asynchronous i/o methods should provide plenty
of performance without worrying at all about thread priority.
Pete
