Read ini file with multiple threads

Question

I have a state machine architecture, but I have multiple threads. For instance, one is dealing with listening for mulitple tcp connections and storing their refnums to an array in a functional global. Another thread is accessing these refnums and collecting data it's receiving from each tcp connection. This data is queued up and then dequeued in a third thread which does some modification and sends it out via serial. My question is, when you have a situation like this and have to read an ini file, where should you read it? It seems like the most logical place would be outside your loops so you can get all the tcp and serial info (port, baud rate, etc) then wire it it to your create listener or initialize serial connection despite them being in different threads. But then again, normal state machine architecture would want an "initialize" case. If you did this though which loop would you put the init case in? And you would then have to worry about synchronizing loops becuase you wouldn't want one to try and create a listener while another thread was still reading ini data which would include the port to listen on. Maybe I'm overthinking this haha. Suggestions? Edit: one more question. Does it seem overkill that I have a tcp loop listening for data and queuing it up and a separate loop sending out the processed data via serial? Or should I just have one state that gets tcp data stores it in a shift register, then another state that sends it out via serial, and returns the state machine to the tcp read state?
Message Edited by for(imstuck) on 03-03-2010 01:13 PM
Message Edited by for(imstuck) on 03-03-2010 01:17 PM
CLA, LabVIEW Versions 2010-2013

Answer 1

Most of the applications I work on at the moment are used for testing barcode and label printers. The test applications I design are focused on testing the printer's firmware, not the hardware. Within our applications we have three primary objects (Unfortunately they are not native LabVIEW objects yet. They were developed before native LVOOP.) The primary objects we use in our applications are a log object, a connection object (communication interface to the printer) and a printer object. In any single instance of a test we only have a single printer, a single connection to the printer and one or more discrete logs. Each instance of these objects represent a single, real physical entity. A singleton object is a virtual representation of the physical world. Let's take the log object since that is the most simple of the objects described above. Naturally for a given log file you have the log file name and path. We also provide other attributes such as the maximum size of a single file (we allow log files to span multiple files), whether it is a comma delimited file or if it contains raw data, if timestamps should be included with a log entry and so forth. Most of these attributes are static for a log file with the exception of the name and such things as whether the logging is actually enabled or disabled. If we split a wire and had multiple instances of the log file (the way native LVOOP actually works) the attribute for whether logging is currently enabled or disabled will only pertain to the specific instance, or specific wire for the that object. Since this truly represents a single item, one log file, we need that attribute to be shared for all references to the instance of the log object. Since we allow this we can set an attribute on the log object in any task and it will be reflected in any other task that is using it. Think of the way a action engine or functional global works. However, in this case we provide discrete methods for the various actions.
I hope that made some sense. If not let me know since I just whipped up this response.
Mark Yedinak
"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot