Threading in LabVIEW

[barlaw]

In JAVA threads are programmed like this:

class ThreadDemo extends Thread {
   private Thread t;
   private String threadName;
   
   ThreadDemo( String name){
       threadName = name;
       System.out.println("Creating " +  threadName );
   }
   public void run() {
      System.out.println("Running " +  threadName );
      try {
         for(int i = 4; i > 0; i--) {
            System.out.println("Thread: " + threadName + ", " + i);
            // Let the thread sleep for a while.
            Thread.sleep(50);
         }
     } catch (InterruptedException e) {
         System.out.println("Thread " +  threadName + " interrupted.");
     }
     System.out.println("Thread " +  threadName + " exiting.");
   }
   
   public void start ()
   {
      System.out.println("Starting " +  threadName );
      if (t == null)
      {
         t = new Thread (this, threadName);
         t.start ();
      }
   }

}

public class TestThread {
   public static void main(String args[]) {
   
      ThreadDemo T1 = new ThreadDemo( "Thread-1");
      T1.start();
      
      ThreadDemo T2 = new ThreadDemo( "Thread-2");
      T2.start();
   }   
}

Executing above code will produce following result:

Creating Thread-1
Starting Thread-1
Creating Thread-2
Starting Thread-2
Running Thread-1
Thread: Thread-1, 4
Running Thread-2
Thread: Thread-2, 4
Thread: Thread-1, 3
Thread: Thread-2, 3
Thread: Thread-1, 2
Thread: Thread-2, 2
Thread: Thread-1, 1
Thread: Thread-2, 1
Thread Thread-1 exiting.
Thread Thread-2 exiting.

Is this possible in LabVIEW OO? If so where can I find some more information/ sample code?

I would like to have two classes, the thread and the class that starts the thread(s).

Thanks in advance!
 

Edited September 22, 2014 by barlaw

[ShaunR]

Is this possible in LabVIEW OO? If so where can I find some more information/ sample code?

I would like to have two classes, the thread and the class that starts the thread(s).

 

 

No and you can't (nor should you want to)

 

Text-based programmers must learn new, complex programming practices to create a multithreaded application. However, all LabVIEW applications are automatically multithreaded without any code modifications.

 

LabVIEW Threading Model.

 

For a detailed technical description see section 9.7 of this document

Edited September 22, 2014 by ShaunR

[GregFreeman]

Implicit FTW.

[MikaelH]

When I like to run things in different thread, and don’t like to make a fixed amount of while loops on my diagram. I use Active Objects.

I’ve created a demo application that does exactly what your Java Code is doing.

To be able to do this quick I use GDS which will make 80% of the code for me.

 

Cheers,

Mike

Threads.zip

[SDietrich]

Hi Barlaw,

 

it is possible in LabVIEW and you do not have to use OO (LabVIEW is not really good at OO). The keyword here is asynchronously calling VIs. It does exactly what you do in your JAVA example:

• You create a worker class (a LabVIEW VI that does the actual work, e.g. calculations).
• You start one or more instances of this worker-VI from you main VI (or even from the worker VI itself).

I use this technology to let my users choose, how many heavy-duty-threads a program should start: only one if they are actively using their computer or up to 8 if they run the program during their lunch break or a meeting and they don't need the computer.

 

In your JAVA-example, you use the call-and-forget strategy, e.g. the workers do not return anything. In LabVIEW you can also use the call-and-collect strategy. Here every worker returns values that you can receive via the wait-on-asynchronous-call node. This node can be placed anywhere in your program, it does not have to be in the VI that started the worker-VI.

 

Regards,

 

Sebastian

[shoneill]

Hi Barlaw,

 

it is possible in LabVIEW and you do not have to use OO (LabVIEW is not really good at OO). The keyword here is asynchronously calling VIs. It does exactly what you do in your JAVA example:

 

Sebastian

 

It's actually much easier than that, it's simply two while loops in parallel.

 

Done in two minutes.

 

Shane.

[Phillip Brooks]

Hi Barlaw,

 

it is possible in LabVIEW and you do not have to use OO (LabVIEW is not really good at OO). The keyword here is asynchronously calling VIs. It does exactly what you do in your JAVA example:

• You create a worker class (a LabVIEW VI that does the actual work, e.g. calculations).
• You start one or more instances of this worker-VI from you main VI (or even from the worker VI itself).

I use this technology to let my users choose, how many heavy-duty-threads a program should start: only one if they are actively using their computer or up to 8 if they run the program during their lunch break or a meeting and they don't need the computer.

 

In your JAVA-example, you use the call-and-forget strategy, e.g. the workers do not return anything. In LabVIEW you can also use the call-and-collect strategy. Here every worker returns values that you can receive via the wait-on-asynchronous-call node. This node can be placed anywhere in your program, it does not have to be in the VI that started the worker-VI.

 

Regards,

 

Sebastian

 

I guess I was stuck in 8.6 for so long that I never learned this. Thanks! 

[hooovahh]

I guess I was stuck in 8.6 for so long that I never learned this. Thanks! 

Welcome to the future.  You probably don't need me saying this but 8.6 was released over 6 years ago.  Not that that means you need to upgrade but there's a bunch of good stuff since then.  Oh and I think things like Call and Forget and the Static VI reference were added in LabVIEW 2011, someone correct me if I'm wrong.

[MikaelH]

 (LabVIEW is not really good at OO).

 

I don't agree  , LabVIEW's OO is almost perfect, if we just had native interface, it would be perfect.

[Mike Le]

Just a warning about using ACBR nodes, as this was an issue I was bit by recently. It sometimes causes project hanging problems.

 

http://digital.ni.com/public.nsf/allkb/2EE8B4884922F2E686257D580053BDB1

 

The Knowledge Base article says it primarily affects 2013 and 2014, but I suspect that's because the bug is most apparent when using AF, and Launch Actor was modified in 2013.

 

I don't think that guarantees the bug wouldn't appear in older versions if you started using ACBR nodes in different ways, just that mostly AF users have noticed the bug. You PROBABLY won't ever see this problem arise, but if you do, the ACBR node is a good place to check for problems.

[odoylerules]

I don't agree  , LabVIEW's OO is almost perfect, if we just had native interface, it would be perfect.

 

 

....... I think a lot of people would disagree with that, but that's probably a topic for another thread  

[GregFreeman]

....... I think a lot of people would disagree with that, but that's probably a topic for another thread

LabVIEWs OOP (Think VI server) is nearly perfect IMHO. Incredibly readable and intuitive. LVOOP, however, has plenty of room for improvement. It is important to distinguish between the two.

 

We also get into questions of is LVOOP the problem or is the IDE the problem...

 

...and here we go....let me just trail off

Edited October 3, 2014 by GregFreeman

[ShaunR]

We also get into questions of is LVOOP the problem or is the IDE the problem...

 

...and here we go....let me just trail off

 

Congrats. Here's your promotion

Edited October 3, 2014 by ShaunR