Tag Data design for parallel read/write

[wiebe@CARYA]

---

@OneOfTheDans wrote:

---

wiebe@CARYA wrote:

Add normal globals to that list. Read and Write are 'split' by default, so you always get (the risk of) race conditions. If you wrap the global access in a VI, you're back to blocking...

---

If 1 global/tag or 1 global/instrument, I still have the issue of needing to pre-define all my instruments at edit time (no dynamic loading). I think Shared Variables are essentially the same as globals. Either could be made dynamic, like the Global: Map( tag: value ), but it's so race-prone it's basically guaranteed to squash data from any writes.

Your comments reminded me that Notifiers exist and could maybe be used here... I wonder how bad the overhead is for LabVIEW to maintain a few hundred Notifiers?

---

If you really need global data, I'd at least try to minimize the scope.

I wouldn't give instruments global data, but make instruments focus on doing their thing (single responsibility). The data coming from the (dynamically started) instruments can be collected, either in a global data bus, DVR, queue, user event, etc..

Notifiers are too complex for my taste. I know they're potent, and people use them. I'm pretty sure they are optimized very well, like queues.

[deceased]

---

wiebe@CARYA wrote:

---

---

That's new to me. How?

---

I think that happened in 2017. Sure its a right click on the DVR node in the IPE structure.

[wiebe@CARYA]

---

@deceased wrote:

---

wiebe@CARYA wrote:

---

---

That's new to me. How?

---

I think that happened in 2017. Sure its a right click on the DVR node in the IPE structure.

---

Mark As Modifier? That doesn't avoid blocking...

[Kevin_Price]

---

wiebe@CARYA wrote:

---

@OneOfTheDans wrote:

---

DVRs can allow parallel read-only access.

---

Still, it is not an advantage over FGV (nor globals). When  reading data from a FGV it won't block execution, as the read would be very fast..

---

I actually ran into a corner-case exception to this many years ago.

We had an RT system that used an FGV as a shared "tag engine" of sorts (we referred to it as "data soup").   Most modules ran in sequence, but we had a main time-critical process that ran in parallel to the sequencer.

We noticed that our 1 kHz time-critical loop would normally execute in a small fraction of a msec, but would occasionally spike up to be slightly over 2 msec in an erratic pattern.

It turned out that one of RT's rules about "priority inversion" was the root cause.  When the time-critical loop was ready to execute an FGV read but some other lower-priority process was in the midst of using it, the priority inversion avoidance algorithm would kick in to bump the low-priority process and give priority to the time-critical process first.

   So far so good, *except* that the mechanism for performing this act took 2 msec each time it was thought to be needed.  Here's a prior post with a little more info (and the solution we settled on).

Dunno if any such issue is still in place under newer RT OS'es.

-Kevin P

[Kyle97330]

---

wiebe@CARYA wrote:

---

@deceased wrote:

---

wiebe@CARYA wrote:

---

---

That's new to me. How?

---

I think that happened in 2017. Sure its a right click on the DVR node in the IPE structure.

---

Mark As Modifier? That doesn't avoid blocking...

---

That's the left node.  You have to do it on the right node.

When you do that, it changes from a pen to a bunch of stacked glasses:

[Kevin_Price]

Pointless comment:  seems like an odd choice to put it only on the output-side node.   Makes more sense to declare it as read-only on its way *into* the IPE structure...

-Kevin P