Issue with DVR parallel reading

[Samuel_James]

In am using LabVIEW 2023 Q3 32bit. In my project i am using a dvr to share a piece of data to many listeners. I usually update the data in one place but there are multiple readers, To my understanding the dvr ref is locked only while writing and not during reading. Also i enabled "allow parallel read only access" to avoid locking. But in my test the dvr is locked even during reading  I also attached a vi to demonstrate the read locking behavior). Is the behavior as expected or my understanding is wrong with dvr.    

[Yamaeda]

Yes, the InPlace-structure works like a Mutex, so don't have any code in it that takes time (like a wait). Atleast to my understanding.

[Samuel_James]

Thanks for your reply. NI documentation says the following.

You can enable read-only access to the data value reference by right-clicking the border node on the right of the structure and selecting Allow Parallel Read-only Access. When the border node on the right is unwired, LabVIEW allows multiple, concurrent read-only operations and does not modify the data value reference.

What does that mean 🤔

[crossrulz]

What you are seeing is that the long read is blocking the writing.

[raphschru]

It means you must not wire the value to the right-border node to allow parallel read-only access:

Regards,

Raphaël.

[Yamaeda]

---

@Samuel_James wrote:

Thanks for your reply. NI documentation says the following.

You can enable read-only access to the data value reference by right-clicking the border node on the right of the structure and selecting Allow Parallel Read-only Access. When the border node on the right is unwired, LabVIEW allows multiple, concurrent read-only operations and does not modify the data value reference.

What does that mean 🤔

---

If you have e.g. a big array of clusters which has large arrays the access can take some time, i think this allows parallell access in that case.

[cordm]

What crossrulz wrote is what is happening, but the mechanism is not obvious. Access is probably requested by a queue-like mechanism where parallel readers can just go ahead, but when a writer or regular reader is encountered, the queue will not be processed further until all current IPEs have finished execution. The access controller cannot guarantee that a reader is really fast and just let it skip the queue while the writer is waiting.

[raphschru]

Oops, I did not pay attention to your VI in my previous answer...

I can confirm as the others said, the option allows multiple simultaneous readings, but apparently not simultaneous reading and writing.

[Samuel_James]

I or everyone understands long reading is blocking the code. My point is that it should not block when it's in readonly mode.  Thats what this thread is all about. Also that is wat ni documentation says.

[cordm · Accepted solution]

The DVR is not blocked because of the long read. It is blocked by the writer requesting access.

When the fast reader requests access, it has to wait until after the writer's turn - which only gets access when the slow reader is done. I agree that this is not obvious and the documentation should point it out.