Re^2: Threaded RS232 communication

[tobias_hofer]

in reply to Re: Threaded RS232 communication
in thread Threaded RS232 communication

This question is very important. In my case its a integration test system communicating with the target by rs232. What i am sending and receiving are requests for starting test-cases and getting the test-results.To avoid the loss of information i have designed a communication protocol. Thus the communication is going on like a ping-pong game.
Request -RS232-> Target
Target -RS232-> Answer+Acknowledge to requester

Only when the communication sequence is done (test-sequence ended completley - recognised by the state machine) I close the rs232 connection. Thus I can be sure that no information is lost.

Ok, regarding this test-system its a special case but IMHO having a protocol and a communication desgin is helping a lot to avoid loss of data

Best regards!
Tobias

[BrowserUk]

It is easy to reason (and demonstrate) that anything that has been pushed into the Queue prior to the thread being terminated, will still be in the queue and available to any other thread after the thread that queued it terminated. This obvious as were it not the case, Thread::Queue would necessarily be the source of many 'mysterious failures' in threaded code all over.

As the detached read thread will not be terminated until the main thread decides that the program is complete; and it presumably decides based upon the data it has read from the queue; it stands to reason that not only will all of the data required to make teh decision to terminate have be pushed into the queue before the process terminates, it will also have been read from it. Else, how would the main thread make its decision.

Thus, it all comes down to the efficacy of the comms protocol employed and the decision making processes based upon that protocol. The presence of threading and queuing in the communications path employed can have no influence upon either.

[tobias_hofer]

Yes, you are right. The communication protocol and the predefined communication sequences are central and critical to my application.

Once the communication is not "synchronized" (synchronized in sense of the communication flow) the application will get into a "no communication possible" mode.

Having still some messages in the queue would be catastrophic. I handled this by putting complete Protocol Data Units into the Queue. Thus only complete messages will be send. I am expecting an answer+acknowledge per PDU I have put into the queue. This is how I keep it synchronized. I am aware that this is quite simple and puts the protocol to the center of communication. The application will only close the rs232 in case the expected PDU (answer) has already been received and - the most important thing - the test-sequence is ended.

However, in case I would have some more threads working on the queues my concept would break into pieces.. It would be necessary to check by MyQueue->pending() if a messge is pending to be send. Moreover splitting up Messages into several PDU would make things once more complicated I am not sure how I would handle the stuff in this case. I guess I would assemble the message completely before sending it by rs232?

[BrowserUk]

I am not sure how I would handle the stuff in this case. I guess I would assemble the message completely before sending it by rs232?

It's not really possible for me to respond to that (hypothetical?) question without knowing a lot more detail about the application; the protocol(s) and what these "some more threads" might actually be doing.

From a very generic design viewpoint, I generally consider it "bad form" to communicate multiple types of data, or many to many conversations, via a single queue. If you've ever taken part in multi-way, conference calls -- especially intercontinental ones with the added bonus of satellite lag -- you'll understand the problem many to many conversation have.

Queues are relatively cheap structures -- provided they cannot be subject to runaway producer growth -- and I have no problem with using as many as I need. One (producer) to many (consumers) or vice versa is fine -- bread and butter stuff -- provided that all of the 'many' in either scenario are clones doing the same thing, each being equally capable of being the sink (or source) of any message appearing in the queue.

The moment you start being selective about what you will receive from a queue, you've broken the basic tenets of what a queue is and is useful for.