Click here to Skip to main content
14,937,943 members
Please Sign up or sign in to vote.
4.00/5 (1 vote)
I'm new with programing multithreads things, so I'm wondering if anyone could help me.

I have to make a program that receives a serial (and continuous) asynchronized message, and then read it and organize this message.

I'm trying to use a multithread tactic: the first thread is responsible to receive the serial info and write it in a matrix (RxTh[col][row]), one line at a time. Then, the 2nd thread is called, to read each line of the RxTh matrix and search for specific chars (that symbolizes the 'begin line' msg). This thread also have to put this received messages in another matrix (Msg[col2][row2]) separating each line of the msg in a different row in the new matrix.

In the future, I'll have to work with this rearranged lines, and search for specifics information, but I'm not thinking in this part right now.

So, I'm having some problems with this program: -First, I'm losing some pieces of the serial message when I stopped writing to begin the read part. That’s why I've tried to use mutex, or critical section. But it isn't working, and I don’t know why.

-The second problem, is that the second matrix (Msg[][]) has strange sequences of '0' in the middle of some lines, and I'm suspecting that this '0' appears while this thread starts to read a new row of the RxTh matrix. Does it make any sense?

-When I use mutex, can I lock only one row at a time?

If someone could help me, I'll appreciate a lot!!

If you need more information or a piece of the code, just ask me!

Thanks
Posted
Comments
Sergey Alexandrovich Kryukov 25-May-12 14:32pm
   
It looks like you are moving in the right direction, but it's hard to see how to help you, because the questions are too general. How about some code samples?
Of course you could work with each separate row one at a time with mutex, but this is not a core of the technique. The essence here is: you should synchronize access only to the resources to be synchronized, no more. You need to analyze your system accordingly. I don't know what else to tell to help you. Just keep learning, or ask if you have more specific concerns.
--SA
nv3 25-May-12 17:57pm
   
It is not clear to me why you would need a mutlithreaded approach at all. Can you explain why you believe this is necessary.

The part: "First, I'm losing some pieces ....the read part", is not clear to me. Can you explain that a little more detailed, please.

And yes, I think it would help if you showed the essential parts of your code.
SoMad 26-May-12 2:04am
   
I also suggest that you provide some of your code.

I have done a lot of work with RS232 input in my time and I have encountered several pitfalls that I did not expect to stumble across.
You are not specifying if you are using a "real" COM port or a USB COM port device. The USB COM port devices are great, but they do not work 100% as a native COM port and depending on the manufacturer you can run into issues with buffer sizes and read/write timing.

The '0' characters you describe is something I see quite a bit - usually in groups of four '0's. Are you sure they only appear in the second matrix? You should check to see if the characters are in fact read from the COM port and appear in the first matrix as well.

Soren Madsen
Aescleal 26-May-12 3:10am
   
Hi Soren, make this a solution and you'll get a 5 from me! It's good advice well worthy of a decent rating.
SoMad 26-May-12 20:52pm
   
Thank you Aescleal. I have made it a solution and we will see if other people agree :)

Your question is general hence the answer is a bit general too:
1) Using a separate thread for receive is correct (incidentally, if you had to transmit as well, it should run in a separate thread)
2) You should have a "raw" buffer that receives serial stream (not sure why you need the matrix but never mind that) that needs to be protected via a mutual exclusion mechanism since the receive thread and message processor thread both will access it (sounds like you are aware of this)
3) As it was alluded to in Soren's posts, from my experience as well, the easiest and fastest way to achieve efficient operation may be to a) grab the mutex, b) copy data from a raw receive buffer to a secondary buffer and 3) then release the mutex. This means your serial receiver thread almost never blocks and your data processor thread can operate on the secondary buffer at its leisure.
4) You have to make sure that you are processing your messages faster than they arrive (producer/consumer issue). It is almost never an issue given serial comms are extremely slow compared to what CPU power you have available to process data.
5) If you are writing in C++, you must be using SetCommTimeouts at some point to setup your port - double check it and make sure you understand all members of COMMTIMEOUTS structure as they will have a substantial impact, in particular IntervalTimeout and TimeoutMultiplier. You may be seeing zeros because your ReadFile times out.
6) And finally, the obvious thing to do to debug your program is to make sure that in its bare form, it is receiving correct data. That should be established before you do any processing of data.
   
I previously posted a response regarding general COM port functionality. I would like to make a suggestion regarding your program structure.

There are obviously many ways of doing the data flow, but given your explanation, I would suggest that you change things around so the thread reading from the serial port passes the data to the second thread without writing it to the first matrix.

To pass the data, I would simply allocate a new byte buffer, copy the data to the new buffer and post a thread message with a pointer to the new buffer and the byte count. When the second thread receives this message, it can process the data, writing it to the first matrix (if you actually need that matrix after this change) and to the second matrix after identifying the message parts.
The second thread will be responsible for deleting the data after processing it.

Some developers do not like this approach and will argue that all the allocating and deallocating is inefficient, but I believe you will get a better flow in your program and you do not have to use the mutex.

Soren Madsen
   
I have done a lot of work with RS232 input in my time and I have encountered several pitfalls that I did not expect to stumble across.
You are not specifying if you are using a "real" COM port or a USB COM port device. The USB COM port devices are great, but they do not work 100% as a native COM port and depending on the manufacturer (most of them seem to use an FTDI (www.ftdichip.com) driver) you can run into issues with buffer sizes and read/write timing.

The '0' characters you describe is something I see quite a bit - usually in groups of four '0's. Are you sure they only appear in the second matrix? You should check to see if the characters are in fact read from the COM port and appear in the first matrix as well.

Soren Madsen
   
Comments
Aescleal 27-May-12 2:09am
   
As promised :-)

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)




CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900