07-07-2011 02:18 PM
Has it been so long since I programmed LabVIEW that I forgot some basic stuff??
I have a main VI which originally called dynamic processes in parallel.
I then called the sub-vi's dirtectly and still run them in parallel, but thwey now have seperate names.
I use a QSM. Each parallel thread now has it's own QSM, because although I was using a Queue Name for each dynamic queue, the data that was being extracted was shared or done between the two threads. If I confused everyone with the statement, I shall explain.
Two parallel processes, calling a QSM (re-entrant). They have the same number of elements and matching sets.
EX:
Process 1 Process 2
Task1 Task1
Task2 Task2
Task3 Task3
Task4 Task4
Task5 Task5
Task6 Task6
I was expecting each thread (each process) to extract from the queue the list of tasks as entered (from Task1 to Task6). What the processes were getting was the following:
Process 1 Process 2
Task1 Task1
Task2 Task3
Task4 Task5
Task6 default
Each Process was sending a different Queue Name to the QSM. Each queue should have it's own name.
I need to get this running by tomorrow with no excuse! So I decided to do a lame workaround by also having 2 QSMs. That fixed it..
In each parallel process (which are a copy of each other with different names) there is a call to open a telnet session. I probed and placed breakpoints in the code. Although each process has a different name and the call to the function that opens the telnet session is re-entrant, the very same telnet reference number is assigned to both processes.
Why? Why would they get the same reference number? I made all vi's down to (and including) Telnet Open Connection as re-entrant (although it was not needed) and it still assigns the same reference number to each telnet session. Why? What I am not seeing? What am I missing?
Unfortunately, I cannot post the code.. But it is not complicated code. Just 2 sessions with different IP addresses. I would expect different telnet session references...
As a matter of fact, I need to try something silly..
07-07-2011 02:27 PM
I forgot to mention:
Using LabVIEW 2010 SP1 on WinXP Pro.
Developing code using LVOOP.
I noticed that I have some invalid object references, which might be causing this issue.
Please ignore this thread until I post more info...
😞
07-07-2011 02:54 PM
Are your re-entrant VIs configured as Shared Clones, or pre-allocated? If the former, be careful - it's actually possible that you would only have one instance of the re-entrant VI if the two instances never execute at the same time, in which case they would share data (for example anything stored in a shift register). Even if the two copies do sometimes execute at the same time, they could get "swapped" between threads, resulting in shared data. Make sure that you pre-allocate clones if you need each instance to have separate data.
07-07-2011 03:14 PM
I should provide more details with the solution....
I just have to stop saying "D'Oh!!"
Okay... here goes...
In the LVOOP, I am using Notifiers and Semaphores to ensure that a race condition cannot occur. Works well with previously written code.
In this particular implementation, I have the same / similar object being created more than once (twice at this time).
Where I went wrong (D'Oh!!!!), was to have a static name for a given object when creating the Notifier and Semaphore references. Since the same name was given, so was the reference. SInce the references were the same, so was the data, and so on.
D'Oh!!!!!!
D'Oh!!!!!!
Now I know why a particular bird was called D'Oh-D'Oh bird... 😞
D'Oh!!! Such a silly mistake...
D'Oh!!!
Hope it makes a few people laugh... or help another bird....