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

[torekp]

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.

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?

[LAVA 1.0 Content]

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">

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

[mbrowne]

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.

[Jeffrey Habets]

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.

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:

[shoneill]

After exiting the lower loop, simply wire a constant to a local variable for "State" to reset it to a value which won't cause the observed problem.

BTW, I'm also of the opinion that the pre-set value of "State" is your problem.....

Shane.

[torekp]

Thanks guys! That was quick - and sure enough, I was being a moron Doh!

[shoneill]

QUOTE (torekp @ Sep 16 2008, 03:31 PM)

Thanks guys! That was quick - and sure enough, I was being a moron Doh!

Not at all.

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

Well it's happened to me anyway...

Shane.

[LAVA 1.0 Content]

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