> Atomicity: Hopefully somebody from NI can jump in and write a full manual
> about atomicity, because it is CONFUSING in labview. Search for atomic on
> ni.com and get scientific results, or atomicity and get zero results;
> useless!!
>
The reason you won't find it mentioned is that you don't generally need
to worry about it on the diagram. All globals and locals property
nodes, controls, etc. are written and read atomically. The dataflow
diagram takes care of most storage access, and for things like globals
where it doesn't, the access is protected. The only time you would need
to be concerned with an atomic access is if you were inside of a DLL,
CIN, or driver that you were adding into LV. What you do have to be
concerned about is the next level up, which we generally refer to as a
race condition. This occurs when you have multiple unsynchronized
writers, commonly when multiple accessors are trying to do
read/modify/write and do no locking of the resource around the read/write.
> Difficulty: Ok so let's say you have a global and want multiple threads to
> read/write properly, but want to make no assumptions? Or more likely you
> have some other shared resource. Consider a lock! You can use their
> semaphores but those don't atomically test-and-aquire. You'll probably need
> to make sure that if re-entrantcy is unchecked your VI will be executed
> atomically.
>
The LV semaphores, mutexes, rendesvous, and queues are internally
implemented on top of OS resources and test and increment instructions,
so they are as atomic as one can get, even on multi-CPU computers. You
should use these to synchronize access when it is important to restrict
access due to there being more than one writer with no apriori
synchronization between them. Also keep in mind that non reentrant VIs
act as a critical section, guarded so that only one call is active at a
time. Reentrant VIs are safe as long as they only use local resources
like shift registers or control values, no globals or global data.
> However this is tough. That might be why globals are generally discouraged.
> Just like in any programming language, globals deal with shared resources
> which the average lackey does not understand.
>
One reason that globals are not overly encouraged is that their overuse
lead to diagrams that are difficult to read or debug -- the biggest
problem being race conditions between writers. Because the globals are
protected, they can also turn into a performance problem if used inside
of really tight loops. One solution you will frequently hear is to
switch to LV2 style globals. These are named this way, because globals
weren't built into LV until LV3. In previous versions, you constructed
your own global by making a VI with state information updated as a
side-effect of a call. Look at them in the examples folder for more
info. The benefit you can gain from them is to localize the access to a
single function, which automatically has a critical section, a much
simpler way of atomicity compared to semaphores, and since you have a
diagram there, you can place common access patterns into the global VI
and simplify your code and improve performance since the locked access
and copying is minimized.
Greg McKaskle
