LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Race conditions with DVRs?

Solved!
Go to solution

Hey,

 

I am just trying to update my knowledge concerning FGVs and thus I stumbled upon an alternative using DVRs (data value references).

Manipulation would then take place with Inplace elements, using the data value reference and manipulating it.

 

My scope is to find a way to manipulate a "bigger" cluster without race conditions. If I use FGVs to avoid the race conditions I would have to add a terminal for each cluster element I would like to manipulate. That could mean quite a lot of terminals if you have a e.g. a cluster with 10 elements.

 

Now the DVRs look quite nice as an alternative. The only question I have is: is the inplace element structure insensitive to race conditions?

If e.g. Element 1 is opened by the first inplace element struct and is now in the middle of modification, is it possible for the second inplace element structure to already read the (currently still unmodified) data? That would then in my opinion lead to a race condition.

 

In the attachment you find a simple example vi of the way I would like to use it.

 

Unfortunately I lack in generating a test vi to securely verify if there is a race condition or not (->Monday morning?).

 

Maybe some of you guys have experience with DVRs and can help me out.

0 Kudos
Message 1 of 6
(2,913 Views)

IIRC, the operations as I see them on your BD should each be essentially atomic, completed without and side-effects and free of race conditions.  If one IPE is already doing something, the others need to wait before they can gain access to the DVR.  However, once you create a dependency between two individual IPEs (Like reading a string in IPE 1, doing something else and then writing a modified string back in IPE 2) then you're back in race condition territory.

 

Just make sure your operations are completely contained within a single IPE and they should be fine with regard to race conditions.

Message 2 of 6
(2,902 Views)

Thanks for the fast response! That is great news. That would simplify data handling very much. I am just trying to create an example to test the race conditions. Once finished, I will upload it and hopefully verify that.

 

Thanks again!

0 Kudos
Message 3 of 6
(2,898 Views)

Ok, test is done. In the attachment you find a vi that contains a cluster with multiple elements, starting two inplace elements that each manipulate an individual cluster element. The first IPE contains a waittime of 1500 ms whereas the second IPE starts after 500 ms. In case of race conditions, the result should not contain both modified values.

But in fact just as Intaris suggested, both values remain and thus there is no race condition.

 

Thanks!

0 Kudos
Message 4 of 6
(2,893 Views)
Solution
Accepted by topic author Jenso

Since you are investigating race conditions, you might want to give this a good look: A Look At Race Conditions.  What I found doing that article and my NI Week presentation was that Action Engines are great for smaller data sets, where DVRs are great for large data sets.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 5 of 6
(2,868 Views)

Dear crossrulz,

 

thanks for this link. That is gorgeous. The sum or mean value was the token I was looking for. That way it is really easy to judge whether there are race conditions or not.

 

Thank you very much for the idea, now I can build up my own performance tester!

 

Best Regards

Jensolo

0 Kudos
Message 6 of 6
(2,797 Views)