Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Actors, queues, threads

Solved!
Go to solution

Hi,

I am currently testing different Message transferring methods between many instances of two Zero coupled Actors (name it "A" and "B"). I launch a Controller Actor which launches several actor-pairs. In a for loop I launch A and B Actors. The controller is responsible for somehow transmitting the messages. One version I like is launching a new transmitter-actor for transmitting the message between Nth instance of A (later referred as An) and B. Lets call this actor Tn.

I am curious if I lanuch several An Bn Tn actors how are those assigned to threads... I would like to have the An Bn Tn triplets (for a given n) in the same thread, to have an efficient data transfer with the queues.

Is it important regarding performance how these actors are assigned to threads?

Can I have any effect on Actor to thread assignment (If there is any assignment)?

How do queues work in the background between threads?

If I assign An to Bm (n!=m) runtime, can I reconfigure which actor is in which thread?

Or maybe this topic is totally automated and optimized runtime so I don't have to worry?

Message was edited by: komorbela

0 Kudos
Message 1 of 5
(4,847 Views)

Brief reply because I broke my hand.

VIs are not assigned to threads. The thread that executes any part of a diagram could be different every time the code runs, even between iterations of a loop. You can use the execution system setting in VI Properties to assign to a specific pool of threads, but that is strongly discouraged unless you're an expert (meaning an existing expert has hand walked you through the possible gotchas). Read more in online help.

Message 2 of 5
(3,701 Views)

I have read about the topic what I found but it's still not clear to me. Yes,it's clear that a whole VI is not assigned to a thread, only parts of it, and those dynamically change. What I am afraid of is the following:

1) In case of using a queue statically connected to the enqueuer and dequeuer - for example having those on the same block diagram - the compiler has enough info to efficiently optimize the data transfer that is symbolized to us by queue.

2) In case of dynamically selecting between many hundred actors' queues when deciding to send a message, and doing this selection run-time, is the message transfer optimized? Doesn't it cross too much threads, isn't it copied too many times?

In case of 1) am I too optimistic? In case of 2) am I too paranoid? What is the reality regarding Queues in LabVIEW in a multithreaded multi-core environment?

to AQ: sorry about your hand, hope it gets better soon! (I know it has a well defined healing time, but I still can hope )

0 Kudos
Message 3 of 5
(3,701 Views)
Solution
Accepted by topic author komorbela

> Doesn't it cross too much threads, isn't it copied too many times?

Nope. In general, it isn't copied at all, just its memory address.

There are lots of posts here on LAVA, on ni.com and elsewhere that discuss queues in detail. Their functionality is unaffected by program scale.

0 Kudos
Message 4 of 5
(3,701 Views)

Thanks and sorry for the low level question, I just did't find any discussion about threading And queues. Only separated, and was not sure about the combination.

0 Kudos
Message 5 of 5
(3,701 Views)