What is a best approach for multithreading on SerialPort

Question

as I am new in multithreaded application I would like to have some advice from more experienced people before starting to write the code...

I need to queue data received on serial port in serial port event for further processing.

So I have the following event handler:

    void jmPort_ReceivedEvent(object source, SerialEventArgs e)
    {
        SetStatusLabel("Iddle...", lbStatus);
        SetPicVisibility(ledNotReceiving, true);
        SetPicVisibility(ledReceiving, false);

        String st = jmPort.ReadLine();
        if (st != null)
        {              
            lines.Enqueue(st); //"lines" is the ConcurrentQueue<string> object 
            StartDataProcessing(lines); //???
            SetStatusLabel("Receiving data...", lbStatus);
            SetPicVisibility(ledNotReceiving, false);
            SetPicVisibility(ledReceiving, true);
        }
        else
        {
            jmPort.Close();
            jmPort.Open();
        }
    } 

Within the StartDataProcessing I need to dequeue strings and update MANY UI controlls (using the InvokeRequired...this I already know :-)).

What is the best approach and colision free (without deadlock) approach to achieve this?

How to call StartDataProcessing method in more threads and safely dequeue (TryDequeue) the lines queue, make all needed computations and update UI controlls?

I have to appoint that the communication is very fast and that I am not using the standard SerialPort class. If I simply write all received strings without further processing to console window it works just well.

I am working in .NET 4.5.

Thank you for any advice...

Updated question: Ok, so what will be the best way to run the task from the datareceived event using TPL? Is it necessary to create another class (object) that will process data and use callbacks to update UI or it is possible to load some form method from the event? I'll could be very happy if someone can give me the direction what exactly to do within the datareceived event. What to do as the first step because studying all possible ways is not the solution I have time for. I need to begin with some particular way... There is so many different possible multithreading approaches and after reading about them I am still more confused and I don't know what will be the best a fastest solution... Usual Thread(s), BackgroundWorker, TPL, async-await...? :-( Because my application uses .NET 4.5 I would like to use some state-of-the-art solution :-) Thank you for any advice...

Answer 1

So after a lot of trying it is working to my satisfaction now. Finally I've used the standard .NET SerialPort class as the third-party Serial class causes somae problems with higher baudrates (115200). It uses WinAPI directly so the finall code was mixed - managed and unmanaged. Now, even the standard .NET 4.5 SerialPort class works well (I've let my application successfully running through a whole night).

So, for everyone that need to deal with C#, SerialPort and higher rates (only for clarification - the device sending messages to PC is the STM32F407 /using USART 2/. I've tried it also with Arduino Due and it works as well) my datareceived event is in the following form now:

    private void serialPort1_DataReceived(object sender, System.IO.Ports.SerialDataReceivedEventArgs e)
    {
       //the SetXXXXX functions are using the .InvokeRequired approach 
       //because the UI components are updated from another thread than 
       //the thread they were created in

        SetStatusLabel("Iddle...", lbStatus);
        SetPicVisibility(Form1.frm.ledNotReceiving, true);
        SetPicVisibility(Form1.frm.ledReceiving, false);
        String st = serialPort1.ReadLine();
        if (st != null)
        {
            lines.Enqueue(st);
            Task.Factory.StartNew(() => StartDataProcessing(lines)); // lines is global ConcurrentQueue object so in fact there is no need to pass it as parameter
            SetStatusLabel("Receiving data...", lbStatus);
            SetPicVisibility(Form1.frm.ledNotReceiving, false);
            SetPicVisibility(Form1.frm.ledReceiving, true);
        }
    }

Within the StartDataProcessing function: 1. TryDequeue(lines, out str) 2. Use the ThreadPool.QueueUserWorkItem(lCallBack1, tmp); where tmp is needed part of the str (without EOF, without the message number etc.)

lCallBack1 = new WaitCallback(DisplayData);

Within the DisplayData function all the UI controls are updated

This approach mixes the ThreadPool and TPL ways but it is not a problem because the ThreadPool is used by TPL in background operation anyway.

Another working method I've tried was the following:

ThreadPool.QueueUserWorkItem(lCallBack, lines); 

instead of :

Task.Factory.StartNew(() => StartDataProcessing(lines));

This method was working well but I've not tested it in over night run.

By my subjective perception the Task.... method updated the controls more smoothly but it can be only my personal feeling :-)

So, I hope this answer will help someone as I know from forums that many people are dealing with with unreliable communication based on the micocontroller <--> PC

My (surprising :-) ) conclusion is that the standard .NET SerialPort is able to handle messages even at higher baudrates. If you still run into troubles with buffer overrun then try to play with the SerialPort buffer size and SerialPort threshold. For me the settings 1024/500 are satisfactory (max size of the message send by microcontroller is 255 bytes so 500 bytes means that 2 messages are in buffer before the event is fired.)

You can also remove all SetXXXX calls from the datareceived event as they are not really needed and they can slow down the communication a little...

I am very close to real-time data capturing now and it is exactly what I've needed.

Good luck to everyone :-)

Answer 2

Within the StartDataProcessing I need to dequeue strings and update MANY UI controlls

No, you do not. You need to dequeue strings and then enqueue them again into the multiple queues for the different segments of the UI.

If you want to be fast, you scatter all operations and definitely the UI into separate windows that run their own separate message pumps and thus can update independently in separate UI threads.

The general process would be:

• 1 thread handles the serial port and takes the data and queues it.
• Another one dequeues it and distributes it to separate processing threads from which
• the data goes to multiple output queues all responsible for one part of the UI (depending on whether the UI Will turn a bottleneck).

There is no need to be thread safe in dequeuing. How serial is the data? Can you skip data when another update for the same piece arrives?

Read up on TPL and tasks - there are base libraries for parallel processing which come with a ton of documentation.