Race condition using Data Value Reference?

[LV_Dan]

I am having an issue that presents itself as a race condition using DVRs to pass data throughout a VI.  I was under the understanding that the DVR blocked simultaneous access to the data reference.  I access a DVR from two places in my code, 1) I write a new value to the DVR, this happens on a user event and is fired infrequently, and 2) I read the DVR to access the data and display it as a graph in a loop updating at 2Hz.  The DVR stores a large cluster of elements, and in this case I am only accessing a single element of the cluster using the "In Place Element" structure.  I am running into trouble that on some occasions the DVR reads out the old data, rather than the new data set by the user event.  I have attached screenshots of the access VIs and I am using a Get/Set configuration that allows me to read/write a single cluster element of the DVR.

I would appreciate any comments on the structure I am using, pitfalls, or if I am misunderstanding the use of the DVR.

Thank you
Dan

[Ben · Accepted solution]

In can only protect what is inside the DVR inplace structure. Once outside all bets are off.

Sounds like you want a queue where there is only a value if the send queued it up.

Ben

[LV_Dan]

This still doesn;t make sense why data would be getting overwritten.  The only place the data is written is inside the structure.  In the case if Set.png, I write a new value from the control input, and in the case of Get.png, it reads the current value and places it back in memory.  It seems to me that these two actions should be blocked from occurring at teh same time.  But that is not what I see.

Dan

[Ben]

---

@LV_Dan wrote:

This still doesn;t make sense why data would be getting overwritten.  The only place the data is written is inside the structure.  In the case if Set.png, I write a new value from the control input, and in the case of Get.png, it reads the current value and places it back in memory.  It seems to me that these two actions should be blocked from occurring at teh same time.  But that is not what I see.

Dan

---

What evidednce do you have the two opeartions are happening at the same time?

LV is by default multi-threaded so the two operation can be occuring close in time while not at the same time.

It just sounds like your read is happening prior to the write.

Show some more code if you think there is an issue.

I am fast to jump on bugs if you can offere evidence to suppor the bug. So far it sounds like a race condtion.

I'll watch for your reply.

FYI:

You would be better served if you un-mark my reply as a solution. Many of those that help out here will ignore a thrad that is marked solved. Until you get an answer, I suggest you keep this thread as "un-solved".

Ben

[LV_Dan]

Ben,

Thanks for the quick replies.  I found another place in the code that I was writing to the DVR, so it was a race condition.  I found this after my reply and therefore marked it as solved, which it now is.

Thanks

Dan

[Ben]

---

@LV_Dan wrote:

Ben,

Thanks for the quick replies.  I found another place in the code that I was writing to the DVR, so it was a race condition.  I found this after my reply and therefore marked it as solved, which it now is.

Thanks

Dan

---

Cool.

Thank you.

Please excuse me if you know this alrady (its hard to tell from where I am sitting) but long before the DVR was invented, we used a code construct called an Action Engine to allow sharing data between threads in a manner that prevented Race Conditions. I wrote about them in my Action Engine Nugget found here.

If you already knew about them, please excuse, I'm only trying to help.

May you wires all be straight and all of your buffers be reused,

Ben