http://www.perlmonks.org?node_id=1016412


in reply to Threaded RS232 communication

Hmm... maybe this is a dumb-question, or an unnecessary one, but I do want to cover it just-in-case.   If the port-reader thread that is feeding data into Thread::Queue is terminated in this way, can we in fact be certain that the reader of that queue will in fact receive all of the data that has been sent?   Do we indeed have the means to be certain that every single byte that the client may have transmitted to the port will in fact be accounted-for, even if the final transmission is incomplete?   (I am thinking, not only of the bytes that have been posted into the queue, but also of any bytes that may have been queued-up in the read operation that we are about to shoot in the foot.)

“Just askin’ ...” ... but not entirely with an absence of motive or precedent.   Sometime in my distant past, a project that i was involved in was very seriously bitten by a manifestation of exactly this kind of issue.   Can we ... and I do not know this ... be c-e-r-t-a-i-n that this edge-case is covered?)

Replies are listed 'Best First'.
Re^2: Threaded RS232 communication
by tobias_hofer (Friar) on Feb 01, 2013 at 09:36 UTC

    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
[reply]

      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.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

        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?

[reply]

In Section Seekers of Perl Wisdom