Jump to content

I have a race condition, but I don't see why


Recommended Posts

Here is the block diagram of a little test-program I wrote. It's very messy, I'm sorry - it is only a test which will be discarded soon, so I didn't bother trying to make it look nice.

My problem is: sometimes both loops execute (intended behavior), but sometimes only the top one does.

post-4616-1221564858.png?width=400

I'd attach the VIs too, but they require DLL's which I'm not licensed to spread around. The blue wire originating with OOIrfm Init represents an open link to a Reflective Memory card. The blue-green wire originating with VIG_termin8_files represents an open binary file. These are resources that are shared by the two loops. Is that causing my problem, do you think?

Link to comment

QUOTE (torekp @ Sep 16 2008, 07:40 AM)

Here is the block diagram of a little test-program I wrote. It's very messy, I'm sorry - it is only a test which will be discarded soon, so I didn't bother trying to make it look nice.

My problem is: sometimes both loops execute (intended behavior), but sometimes only the top one does.

http://lavag.org/old_files/monthly_09_2008/post-4616-1221564858.png' target="_blank">post-4616-1221564858.png?width=400

I'd attach the VIs too, but they require DLL's which I'm not licensed to spread around. The blue wire originating with OOIrfm Init represents an open link to a Reflective Memory card. The blue-green wire originating with VIG_termin8_files represents an open binary file. These are resources that are shared by the two loops. Is that causing my problem, do you think?

Code snippets usually read all terminals and nodes that are not delayed by data dependancies, so is there a possiblility that the local for "State" is reading a value of "stop" before its is set to another value?

Ben

Link to comment

QUOTE (torekp @ Sep 16 2008, 12:40 PM)

My problem is: sometimes both loops execute (intended behavior), but sometimes only the top one does.

Before both loops are started the state indicator is not initialised and will most likely be set to "stop" from the previous run of the VI. Now if the bottom loop starts execution before the top loop it will check the state indicator which is set to "stop" and the loop will immediatly exit. However if the top loop starts before the bottom loop the state indicator will be changed (to "wait4Init" initially) before the bottom loop checks its value.

Link to comment

Well, after a quick glance at the code, I see at least one race-conditions that could cause this..

The local variable state in the lower loop could be read before the value is actually initialized in the upper loop. Since the initial value of state will almost always be stop (except for when you first run the VI after opening it, it will have the default value then), this is probably your problem.

post-906-1221568324.png?width=400

So you will either have to initialize this state before you enter both loops, or better, use an occurence to stop the second loop. Here's an example:

post-906-1221568916.png?width=400

Link to comment

QUOTE (shoneill @ Sep 16 2008, 09:44 AM)

Not at all.

Has happened to us all, right guys? Guys? Oh. :(

Well it's happened to me anyway...

Shane.

Yup!

Did it just last week. After restoring class data from file I was failing to clear the array of queues (contained in the class data) that had been used when the file was saved. It took me some digging before I figured out why posting to (now invalid) queues was not working after restoring from file.

Ben

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.