make existing thread into a sub VI

[hounddog]

I have an existing LabVIEW 2009 application that has 5 threads: the first one is the consumer/FSM that is associated with an event loop.  The remaining loops are each dedicated to a TCPIP socket for sending and a separate one for receiving and several UDP ports are operating in other threads.  The block diagram has grown because of the threads and I would like to put each thread into it's own sub VI.  I believe that if I enclose and 'make sub VI' each of the while loops I will no longer be using threads, so I will probably have to make a sub VI  of the contents of each of the while loops (threads) to accomplish what I want.  I will be doing some experimenting with this idea and would appreciate any comments/ideas on this subject.

[Norbert_B]

I think you have a misunderstanding of multithreading in LV.

Using different loops does not mean that you have different threads; additionally, with the exception of the timed structures, a loop does not need to be executed in a single thread.

Please read this whitepaper for some basic information about threading in LV. 

hope this helps,

Norbert 

[Harold_Timmis]

Norbert is correct, but if you want to make existing code into a vi simply select the the area you want to be a subvi and go up to edit->create subvi

[hounddog]

I did read a few things about LV2009 and it's capabilities to multitask and manage threads and I am using a dual processor unit. In the attached snippet there are 2 shots of a simple block diagram where without the semaphores my total consistently runs less than the expected 2000, while with the semaphores, the total always is 2000.  Since I intentionally set this example to show resource contention issues, why would there be any difference unless the while loops were running in separate threads.  Multitasking is a way of sharing one thread from what I remember.  Interestingly, what I did not show was the two additional cases where I used property nodes with and without semaphores, and both cases give the correct answer.  Most likely because the GUI thread is scheduling the calls to the two loops to prevent resource contention.

Still a bit confused, but still hot on the trail....

[F._Schubert]

I do not get what you are trying to do.

But: Using property nodes means a thread swapping to the single (bottleneck) UI thread. So the code actually is running single threaded by the dark force of the property nodes.

Felix

[johnsold]

Snippets change local variables into references and value property nodes, so your cases are not significantly different after downloading the snippet.  There was a thread on the Forum about this a few weeks ago.

Can you attach the actual VIs?

Lynn 

[hounddog]

This simple example shows resource contention for a local variable without semaphores being used.  Typically, my result is quite a bit different than the expected 2000 total, while with semaphores 2000 is always the result, so I conclude that the two loops are not operating within one thread.  However, when property nodes are used and since property nodes are all run in the GUI thread and managed for me, I do not need the semaphores and, therefore, get the correct result with and without the semaphores being used.

Now suppose I had a lot of code in these while loops and wanted to keep an uncluttered block diagram:  I would think that I should put each while loop into it's own separate sub VI.  My application does used some functional globals and not local variables so I'm not worried about creating references and other such things as I have made many sub VIs and dealt with references and strictly typed ctls and so forth.  Other than these issues, and some others peculiar to my program, how does putting the while loops into a sub VI affect the existing threading vs what would actually happen when I call sub VIs?  My first inclination is that I have radically changed the behavior to a single threaded model.  I don't have the execution trace toolkit yet so I am primarily working from conjecture and experimentation, so any feedback is very welcome at this point in time.