Serial communication in second thread, asynchronously? - asp.net

Question

I want to put the serial communication with an external device to a second thread, c#.
Here there is my first thread doing some stuff.
And there is the serial worker, the second thread:
It opens the serial port
It asks the external serial device regulary: Are you alive?
It receives queries from the first thread with a string and an int like: "Command2", 33 and it should give this to the external serial device.
Sometimes there comes an answer from the external serial device back with a string and an int like: "Command4", 55 and the second thread should give this to the first thread and it should start a process there.
The second thread also does own things like error detection which I want to keep free the first thread of.
Serial communication itself works fine but I have problems with threads, delegates, BeginInvokes, EventHandlers, etc.
My first thread:
Class MainProgramme
{
internal void StartSerialCommunication
{
=> Here I want the second thread to open the serial port and I want to start the regulary serial device check, all in the
second thread.
}
internal bool SerialCommand(string s, int i)
{
=> Here I want to give the command s and i to the second thread asynchronously. That means this process does not wait for an answer from the second thread.
}
The following process should be fired by the second thread because the second thread has received some important data
from the external serial device.
internal void SerialAnswered
{
=> Here I want to get the string and the int from the second device back.
}
}
My second thread:
Class SerialCommunication
{
internal bool SerialDeviceIsAlive = true;
public bool SerialOpen
{
SerialPortMsp.Open();
RegularyDeviceCheckTimer.Enabled = true;
return true;
}
private void RegularyDeviceCheckTimer_Tick(System.Object
sender, System.EventArgs e)
{
if SerialDeviceIsAlive == true)
{
SerialDeviceIsAlive == false;
}
else
{
=> Here I want to inform the first thread that the answer from the external serial device is missing.
}
SerialSend("AreYouAlive");
}
public void SerialReceived(object sender, System.IO.Ports.SerialDataReceivedEventArgs e)
{
IAmAlive = true;
int buff = SerialPortMsp.ReadExisting();
if (buff.IndexOf(new string('\n', 1)) > 0)
{
=> Here I want to inform the first thread that the answer was buff.
}
}
public bool SerialSend(string SerialCommand)
{
SerialPortMsp.Write(SerialCommand.ToCharArray(), 0,
SerialCommand.Length);
return true;
}
}
I need help in calling processes and transferring data between the two threads.

Answer 1

I think both thread1 and thread2 have their "own" execution path, and you can not force them to "interrupt" and do something with the data that you built in the other thread.
What you can do is that you "plan" for the possibility that there is something ready in the other thread that might need your attention in the current thread. Hence, both thread1 and thread2 need a code that regularly checks if there is something "ready" in the other thread.
If you plan to do other things in thread1 you still need to build in a regular check/poll for the results of thread2 and vica versa.
The concrete communication between the threads might be implemented with a queue in each direction. In .NET 4.0 there is a ConcurrentQueue class for thread-safe producer/consumer implementation. When thread1 has a command it should queue it in the command queue, while thread2 should regularly check if there are commands waiting. When thread2 has a result ready, it should queue it in a result queue, while thread1 should regularly check if there is a result and run the processing code accordingly.
Having all this said, I think you should consider once more, if your solution with exactly these two threads is really what you need. However, this depends on the details of your requirements (e.g. what other things thread1 should do in the meanwhile, and what the processing of the command result means, can it run parallel, etc).
My suggestion would be to align your design based on the producer/consumer pattern. That is a typical concurrency task and you will find a lot of explanations and optimized solutions (e.g. where the consumer does not have to poll the queue, but it can sleep on a waithandle, semaphore, or some other construct without using CPU and it can be waken up by the producers if there is something to consume).
In your case you could use this pattern twice. The CommandProducer is the entity that creates the commands and feeds the CommandConsumer (that can consume it by passing it to the serial line). On the back way you have the CommandResultProducer that reads the serial line and passes the result to the CommandResultConsumer to do something with the result. Aligning your code like this would result in a more flexible and clear solution, and you can even increase the number of consumer or producer threads if it turns out to be practical.