LabVIEW

[iCat]

---

P Anand wrote:

---

How about

?

---

You should be more specific when you want to solve any problem. Please do not post very simple question to which the others cannot understand whats in your mind and what you want to achieve. Please explain as much as possible so that you will not be questioned.

Good luck.

---

I want to know if using local variables that way is safe.

[GerdW]

Hi iCat,

as long as you don't write to that local in a different location (producing race conditions!) it's (kind of) safe.

I still would prefer a functional global for that purpose...

[crossrulz]

---

iCat wrote:

---

P Anand wrote:

---

How about

?

---

You should be more specific when you want to solve any problem. Please do not post very simple question to which the others cannot understand whats in your mind and what you want to achieve. Please explain as much as possible so that you will not be questioned.

Good luck.

---

I want to know if using local variables that way is safe.

---

I really depends.  Are the other loops manipulating and writing the value as well?  That would cause a race condition.

Do you NEED to have this value on the front panel?  If it's not part of the GUI, I would recommend the Action Engine to hold the value.  Any manipulation of the data should be performed inside of the AE.

[apok]

---

GerdW wrote:

Hi apok,

do you think it's a good example to dequeue a queue in 2 independent loops?

This will just force questions on race conditions...

---

you could be writing it to two different inputs..(ie voltage supplies)?

[GerdW]

Hi apok,

having two producers in a producer-consumer-scheme is ok, but having 2 consumers as in your example will force race conditions...

[crossrulz]

---

apok wrote:

---

GerdW wrote:

Hi apok,

do you think it's a good example to dequeue a queue in 2 independent loops?

This will just force questions on race conditions...

---

you could be writing it to two different inputs..(ie voltage supplies)?

---

Queues are meant to be many to 1.  Notifiers are meant to be 1 to many.

[P@Anand]

---

apok wrote:

---

GerdW wrote:

Hi apok,

do you think it's a good example to dequeue a queue in 2 independent loops?

This will just force questions on race conditions...

---

you could be writing it to two different inputs..(ie voltage supplies)?

---

You are trying to question GredW or answering him?. The Example you showed doesn't work in the defined way since you are de-queuing the same queue in 2 places

[Ben]

---

iCat wrote:

---

P Anand wrote:

---

How about

?

---

You should be more specific when you want to solve any problem. Please do not post very simple question to which the others cannot understand whats in your mind and what you want to achieve. Please explain as much as possible so that you will not be questioned.

Good luck.

---

I want to know if using local variables that way is safe.

---

Judging by your questions I hope not to be singing an old song to you but...

Please do let yourself be mislead by the term "local variable" and thinking they are the same as locals used in text based languages. While in other lahguages, a local is a name associated with a memory location, in LV a local is a method of accessing a GUI object that should be thought of as an I/I device that lets you update a user or get a selection from a user. We would never think of using a register in the I/O device as a method to share data between threads in other languages and similarly, we should not use locals to share data in LV. They are I/O devices.

There are many methods to share data and comunicate across threads process contexts and platforms for that matter.

One of the simplest to understand, flexible, robust methods is an Action Engine (see the link provided above).

And in the event you missed it...

Local in LV = I/O device.

Ben

[apok]

---

crossrulz wrote:

Queues are meant to be many to 1.  Notifiers are meant to be 1 to many.

---

hmmm,a concept I will ponder about.....thnxs crossrulz!

[crossrulz]

---

Ben wrote:

Local in LV = I/O device.

---

Ben, you always seem to come up with some of the most elegantly simple ways to think about things.