Jump to content
Sign in to follow this  
_Y_

Strange queue/debugging behavior probably related to race conditions

Recommended Posts

Hi all,

 

I got a strange queue behavior that is probably related to race conditions. The problem is eliminated (a way around is found), so there is no need in a quick solution. However, I would be happy to understand reasons for such a phenomenon.

 

BD of the “problematic†VI is attached. The queue size is limited to 1. The program consists of multiple asynchronous processes.

 

Execution reaches the Enqueue Element node than stops. The timeout never happens; the program hangs. However, there is more. If I try to execute the VI step-wise, everything works fine until the execution enters the internal Case Structure. When it enters, three Stepping buttons become disabled.

 

If I try to decompose the program, i.e. to use the same VI in a simple single-process program, both problems disappear.

 

Have you encountered such a strange behavior? Any ideas that can help to the poor creature (me) to avoid sleepless nights?

post-15502-0-29248800-1414139001_thumb.p

Edited by _Y_

Share this post


Link to post
Share on other sites

By "no timeout" you mean the enqueue element doesn't exit after 30s?

 

Yes, it does not exit after 30s or even after lunch. :frusty:

Share this post


Link to post
Share on other sites

To me this is not a race condition. A race condition would for example cause the dequeue function to be called before the enqueue function while you intended otherwise. But the fact that a function doesn't time out while it's supposed to is a bigger issue...

Share this post


Link to post
Share on other sites

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.

Sign in to follow this  

  • Similar Content

    • By Aniket Gadekar
      Hello Everyone,
      I have created this feature to create named variables of any data type in memory and access its value from any part of data code which is under same scope using its name.
      This variables stores instantaneous value. Best use case of this toolkit is acquire data set variable values & read from any loop. Do not use for Read-Modify-Write
      Once variables are created in memory, you can be grouped them and access its values using names.
      You can create variable for any data datatype & access its value using its Name. I have tested this toolkit for memory & performance, which is much faster than CVT & Tag Bus Library
      Please check and let me know your suggestions. use LabVIEW 15 sp1
      BR,
      Aniket Gadekar,
      aniket99.gadekar@gmail.com
      DataVariableToolkit.zip
    • By Aristos Queue
      The TL;DR is in bold.
      I want to add to the Conditional Disable structure a new built-in symbol that toggles when the VI's "Debug Enabled" setting is toggled.
      I've wanted this for a long time, but I finally got around to opening up the code to see what's possible.
      Let me take care of one question right away: I have no idea what version of LabVIEW this might or might not go into. So don't get excited. :-)
      Anyway... it turns out, what I'd like to do isn't straightforward. All existing conditional disable symbols are global to the application instance. The three built-in symbols -- bitness, target, and run-time engine -- are universal to the running environment. The symbols that users can define are in the project and target. In other words, if I want to know the value of any symbol, I just need the reference to the application instance, not to a particular VI. And, guess what, all the C++ code is therefore oriented around application refnums not VI refnums. *sigh*
      Now, it turns out that I can see a way to add the debug-enabled flag in a sort of sideways manner, and I would just hardcode that symbol as a special case in some parts of the code.
      RED FLAG! Alert! Developer has used the phrase "special case"!
      One of my colleagues likes to refer to the "0, 1, Infinity Rule". That is, there are either zero cases of something, one case of something, or an infinite cases of something. There's never just 2. Or 3. Or any other finite number. Basically, as soon as you are prepping the second special case, your code needs to be architected to accept an infinite number of such special cases because otherwise, you're going to build up a huge number of unmaintainable hacks over time. If there really is just one special case, then the code generally remains maintainable. One special case isn't a hack... it's just the special case of the problem you're code is solving. The second special case is a hack.
      I try to avoid hacking up the LV code base and developing more stuff that needs refactoring in the long-term, so I'm hesitating about working on this feature. With this in mind, I went to a couple of other dev and asked a question, and I want to ask the LAVA community the same question:
      Besides "enable debugging," are there any other VI-specific settings that would cause you to want to change the actual code compiled into the block diagram?
      I honestly cannot think of any. Reentrancy? I don't typically change the reentrancy of a VI on a regular basis. A VI is either designed to be reentrant or not... flipping that switch usually changes how the node is used entirely. Thread affinity? I can't think of any VI where I have ever wanted to sometimes have the VI in UI thread and sometimes have it in Exec System One, and where I wanted different code in those cases. No one else I've asked has been able to come up with any scenarios for that sort of thing either. Oh, the hypothetical COULD exist, but hypothetically, I could want the font on all my numeric controls to become italic whenever the VI is set to "run when opened". It ain't a real use case. :-)
      One person suggested that there might not be VI-property-related settings that would want to change out code on the diagram, but maybe there is a case for user-defined symbols at the VI level? Maybe. But, honestly, the Diagram Disable structure pretty much covers the "I want to change out the behavior of this VI". Yes, we all know cases where we have code on the left half of the screen and code on the right-half of the screen, and we need a separate disable structure around those regions... but that's just as probable as having that right-side of the screen dropped into a subVI. The setting then is not a per-VI setting, but it is either a per-project setting (which we have today) or a per-library setting... and that I can easily imagine a use case for. Having a per-VI user-defined setting just seems problematic if you dropped the code into a subVI and lost the link between those two VIs. I hate adding any feature that discourages people from creating subVIs as needed! So I'm rejecting that use case. And the library use case, while a good one, is outside the scope of what I'm asking about today. Go put it on the Idea Exchange if you want to promote it. :-)
      Which brings me back to the "debug enabled" setting. That setting can be programmatically toggled when doing a build (if you go into the custom per-item settings because NI doesn't have an easy single-checkbox for you) and frequently we do things while debugging that would just slow down a release build. Which means it makes sense to write code into the VI that could be either compiled in or compiled out based on the VI's debug settting, unlike any of the other settings.
      So... brainstorms anyone? And please be honest. Even if you want this specific feature, and you think, "Well, if I present this valid use case, it means he won't put in his hack, so I'm cutting my own throat," trust me... for the long-haul, you'd rather LV develop as cleanly as possible, for the sake of your own trust in it!
    • By Aristos Queue
      Giant VI hierarchy. Runs for some long amount of time. Somewhere in the mess, a value is generated that is causing the program to go awry. You only know about it at the point where the program goes wrong, which appears to be a long way from where the value was generated.
      Your challenge: Find the VI that is generating that value and make it generate some other value.
      I've had to debug things like this in LabVIEW before... I just tried something that worked surprisingly well. It works if the value to be generated is somewhat unique in your application (i.e. a particular string or a particular double value... doesn't work so well for common values like "1" that may occur a lot in your application).
      Steps:
      Run a quick bit of scripting to change all of your VIs to enable "Show front panel when called" and disable "Close afterwards if originally closed". See picture. Run your top-level VI. Set a breakpoint in the subVI where things are going wrong -- which you know has to be after the value is generated. (optional) Abort the VI hierarchy. This just cuts down on other stuff happening in the system. Now you can use ctrl+F and do a text find for the value. Because all the panels were open, the value they last emitted is on their panels. Even if it is nested inside an array of cluster of array of cluster of... etc. Even if it eventually got packaged into a DVR or passed through some other data-passing mechanism, the original VI that generated the value will still have the value on its panel unless that VI has been called again for some other purpose. This does slow down your whole application -- having the panel open makes LV spend a lot of time updating the controls and indicators, which is a lot more data copies. But at least in my most recent case, this strategy was effective. I figured I'd pass it along. By using the "Show front panel when called" option, you get all the reentrant clone VIs, which you won't get if you just open all of the source VIs in your project.

    • By Calorified
      I am trying to read the value of some data in a while loop from a sub-vi (attached as FTP WPF UDP below) into the top-level vi (attached as Proportional Controller VI) but I find that the data is timing out in my top-level vi whereas it runs smoothly withing the subvi. I have used the while loop and the timing in the subvi is synchronized to the external code that sends data via udp to the subvi. 
      Is there a way you think this can be fixed?
      Below is my attached code.
      Thank you!
       
      Proportional Controller.vi
      FTB WPF UDP - Original.vi
    • By phurley
      I am mentoring an FRC team and we were discussing a design where we have a couple channels of information, some of which is very high frequency and losing data is not too important, so we are using a notifier. We also have a different channel of data which is much lower frequency, but losing any would be an big problem and we are using a queue.
       
      Now the tricky part we would like to be able to wait on data from either source (preferably not busy wait). I have come up with a a couple possibilities:
       
      Busy wait on both, looping between checking both sources and a 0 delay in the loop to prevent starving the rest of the code.
        Tweak the queue based send to also push data to the high volume notifier, when I get a read on the notifier also check the queue and process it.
        User events? Not sure, but this looks right; however, note that the notifications/queue messages are generated in one subVI (which is called by external framework code) and being sent to another subVI which has a number of long running control loops in it.  
      I was hoping for something a little more elegant, that I have overlooked. Any pointers?
       
      Thanks from an old C programmer still trying to get comfortable in labview.
×
×
  • Create New...

Important Information

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