Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Re^3: Threaded RS232 communication

by BrowserUk (Patriarch)
on Feb 01, 2013 at 10:13 UTC ( [id://1016498]=note: print w/replies, xml ) Need Help??


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

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.

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

    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?

      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.


      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.

        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.

        I am sorry, I missed to tell that for this I am using several queues, not a single one. Got the point ;-)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1016498]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others musing on the Monastery: (4)
As of 2024-03-19 03:03 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found