Jump to content

DVR Read and Write Malleable VIs - Simplify Your Block Diagram


Recommended Posts

I can't say I support the use of the Write DVR Value.  The point of using a DVR is to protect critical sections of code (ie avoid race conditions).  If you are just randomly writing a value to a DVR without doing the Read-Modify-Write protection, you might as well use a Global Variable and get better performance.

  • Like 2
Link to comment
1 hour ago, crossrulz said:

I can't say I support the use of the Write DVR Value.  The point of using a DVR is to protect critical sections of code (ie avoid race conditions).  If you are just randomly writing a value to a DVR without doing the Read-Modify-Write protection, you might as well use a Global Variable and get better performance.

That's a good point that I hadn't considered. In my mind the usefulness of the Write VI is more of the case of quickly initializing or otherwise performing a reset/overwrite of the existing value of the DVR, and to be used in conjunction with the IPE structure and the read/modify/write paradigm as normal. An example for me recently is needing to ensure that a DVR used throughout the application was initialized to defaults after a certain sequence had executed. Hence, wiring a constant to this VI was much more convenient. Does that seem more reasonable, or still prone to error rather than helpful?

I definitely see how this could be misused such that the critical code is placed outside of the IPE. I'll work on coming up with a better example to show more of the specific use case and provide a clearer explanation of when it could be helpful.

Link to comment

Seems nice but last time I have checked there were some serious bugs using this read only feature.  CAR 671221 and I think 3 others. Is there a link at NI site where we can see all bugs and if they were solved?

What is the performance boost when using this read only feature compared to normal read and write?

 

Link to comment

The performance boost can be from more or less negligible to serious. It really depends what else you are doing on that DVR. If there is no other access to the same DVR at the same time, the gain from just locking the DVR for the value read rather than the duration of the entire IPE structure really won't matter at all. There is no other code that could be blocked waiting for the DVR and consequently nothing that could be slowed down. If you have many concurrent read only accesses to the same DVR then you will see a significant improvement.

Before the read only access, each DVR IPE access had to wait for any previous IPE access to that DVR until it was finished. You could achieve similar behaviour before by just using the IPE structure to reference the necessary data in the DVR and do any further processing outside of the DVR. As such the only advantage of the read only access is that the DVR doesn't need to be accessed a second time before leaving the IPE.

If there is a IPE non-read-only access to the DVR active however any read-only access still needs to wait for the write access to finish and therefore can be blocked.

Edited by Rolf Kalbermatter
Link to comment

Makes sense. I remember one project based on GDS and DVR template. We used IPE to read some data all the time. Each IPE was just to unbundle data outside the structure, no processing done inside to avoid longer locks.

It would be nice if the compiler could detect and optimize this when LV is upgraded to new version, so we wouldn't have to go to each IPE and remove write wire.

Link to comment
8 minutes ago, pawhan11 said:

Makes sense. I remember one project based on GDS and DVR template. We used IPE to read some data all the time. Each IPE was just to unbundle data outside the structure, no processing done inside to avoid longer locks.

It would be nice if the compiler could detect and optimize this when LV is upgraded to new version, so we wouldn't have to go to each IPE and remove write wire.

I'm pretty sure that the IPE structure where the DVR wire was directly wired from the left access node to the right access node without doing anything else with the wire (except a unbundle to get some data out of the DVR content) was already optimized by LabVIEW to be more or less a NOP (no operation) for the right access node. The only real impromvement with read-only setting is that the DVR doesn't need to be locked for the entire IPE but only for the read acces at the left access node.

Link to comment
On 7/14/2018 at 6:30 AM, pawhan11 said:

Seems nice but last time I have checked there were some serious bugs using this read only feature.  CAR 671221 and I think 3 others. Is there a link at NI site where we can see all bugs and if they were solved?

 

CAR 671221 was fixed in LabVIEW 2017 SP1. The best place to look is in the bug fixes list for the appropriate LabVIEW version (here is 2017 and 2018) or in the patch details (2017 and 2018).

 

As you'll notice, this specific CAR number is not called out on any of these pages. Not every CAR that is fixed is published online, but you can always contact the support team to determine if a specific CAR was fixed.

Link to comment

Thanks fo reply.

Can I also check list of all bugs still to fix?

Knowing what was fixed without what is still reported/to fix is limiting. 

Sometimes I start an discussion and someone from NI reports this is known bug that will be fixed. If we had acces to reported bugs it could save a lot of time.

Link to comment
  • 1 year later...
On 7/16/2018 at 7:39 PM, pawhan11 said:

Thanks fo reply.

Can I also check list of all bugs still to fix?

No that information is generally only available to people outside of NI on a limited "needs to know" base and the decision for that is handled by AEs for simple issues or the product manager for the product in question for more involved issues.

Link to comment
On 7/13/2018 at 9:17 AM, crossrulz said:

I can't say I support the use of the Write DVR Value.  The point of using a DVR is to protect critical sections of code (ie avoid race conditions).  If you are just randomly writing a value to a DVR without doing the Read-Modify-Write protection, you might as well use a Global Variable and get better performance.

I think it can be useful in cases where you don't need RMR protection and the DVR is part of some sort of data structure that you may have more than one of, making globals not an option or a poorly scaling option.

Link to comment
  • 3 years later...

I like DVRs a lot, as its great to avoid to race condition. However, parallel read only access DVR seems to me as problematic as if have 'Write DVR' in loop 1 and 'Read only DVR' in loop 2 running in parallels loop, and if loop2  running faster, than write DVR would keep waiting forever and code gets locked without any intuitive awareness - facing similar issue. Correct me if I am thinking wrong.

 

Edited by Madhur Kohli
Link to comment

No that should not happen. When the Write loop wants to access the DVR it is either locked or not. When it is not there is no problem. When it is, the IPE in the Write loop is put on a wait queue (with other stuff in the diagram still able to execute and as soon as the DVR is unlocked this wait queue is queried and the according IPE woken up and passed control with the newly locked DVR. If the Read loop now wants to access the DVR, its IPE is put on that same wait queue as a Read access is not allowed as long as the DVR is locked for ReadModifyWrite access.

Two Read accesses on the other side could execute in parallel as there is no chance for a race condition here.

Edited by Rolf Kalbermatter
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.