How to avoid race conditions in Shared cluster variables?

[Monza]

I have a multithreaded application with several parallel loops, and in some cases I want to use shared cluster variables to communicate between the loops. Race conditions are a problem if I want to write to a single cluster element. As far as I understand the only way to write to single cluster element is first reading from cluster, and secondly use the unbundled function to write to the single cluster element and then writing to the complete cluster. A race condition will arise if the loop is pre-empted in between these steps and if a second loop writes to the same cluster. LV2 variables will solve the problem, but this makes the programming more complex. So my question is: Is it possible to write to single cluster element in a single operation to avoid race condition?

Regards Per

[daveTW]

Hi Monza,
this is not possible. Except you don't care for the other values and bundle from a cluster constant. As you mentioned, the LV2- global would solve the problem.
Dave

[Monza]

Thanks Dave!

Ok, I see. I guess i have to it the hard way using LV2 variables then. Sometimes I really miss C programming....

Per

[altenbach]

---

@Monza wrote:

As far as I understand the only way to write to single cluster element is first reading from cluster, and secondly use the unbundled function to write to the single cluster element and then writing to the complete cluster.

---

To only write to a single cluster element, you don't need to unbundle at all. A single "bundle by name" will do the trick. See image.

Message Edited by altenbach on 06-01-2006 12:06 PM

[daveTW]

Hi Altenbach,
as far as I understood Monza, the digram should look like this, including race condition.





Greets, Dave

Message Edited by daveTW on 06-01-2006 09:24 PM

[altenbach]

I was just commenting on how to modify a cluster element, not on the possible race condition.

Yes, a race condition can still exist, for example if two parts of the code read the global at the same time, modify a different cluster element, then write the global back.

As a workaround, you could encapsulate the "global read-->write element-->global write" into a non-reentrant subVI containing only two inputs: (1) an element input and (2) a ring input to decide which element to modify. Now each read-modify-write operation must fully complete before the next one occurs.

My religion prohibits me from using globabl variables, so I would probably try to find a different solution. 😄

[Monza]

Sorry mixed the bundle and unbundle, what i meant was of course the bundle function.

Yes encapsualting the code inside a non-reenrant subVI will do the trick, and i guess the most efficient is to use subroutine priority on the subVI to avoid that the VI is pre-empted during execution.

[Ben]

....

But if you go through the trouble of putting in a sub-VI, then using a shift registerinstead of a globals is a simple modification.

By doing so you

1) pick-up the option to possibility of re-using buffers (if working with arrys)

2) loose the extra memory required to store copies of the global

3) never have to find out "which thread do updates of the Global take place in?".

I strongly urge going the LV2 route.

Ben