Serializin​g read/write operations of network-pu​blished shared variables

Question

Hi all,
I'm developing a distributed application (PC + CompactRIO), and using shared variables (SVs) for inter-device communication. Here's my journey so far:
Intended procedure
PC parses file
PC writes processed file data (custom cluster, large) into the 1st SV 
PC writes a "grab data" signal/command (enum) into the 2nd SV
cRIO polls the 2nd SV
cRIO sees the command, then reacts by reading the 1st SV
Steps #2 and #3 were sequenced, using error wires.
Unexpected results
Even after the command is transmitted and the cRIO sees it, the cRIO could not read the data (which I wrote BEFORE the command) -- LabVIEW reported that the buffer was empty.
The operation succeeded when I placed a wait (5 seconds) between steps #2 and #3.
Questions
What am I doing wrong, and how do I achieve my desired outcome?
Is SV I/O asynchronous by design?
Is it possible to use event-driven programming to handle SV access? (i.e. does LabVIEW signal when the new SV value has propagated across the network?)

Answer 1

BillMe wrote:
Why do you have to "notify" the other end that data is available? The subscriber can simply sit in a loop doing a timed read just as if using a queue or notifier IPC. If it doesn't time out, you got new data. If it does time out, do some other processing if needed and then loop back for another timed read.
My sytem architecture is command-driven -- the cRIO listens for instructions from the PC interface (sent as an enum via one SV), and performs tasks (motor control) in response. One of the commands (the one described in this thread) happens to be "download a new motion profile from the PC, by reading the other SV". Given that the cRIO is already polling the command channel, I felt that there's no need to also poll the data channel (especially since the "download" command is issued very infrequenty). Plus, I thought that polling two channels would increase the chances of race conditions or illegal state transitions, particularly if the app is developed over a long term.
I am also new to LabVIEW, so my current programming style will heavily reflect my C++/Qt background while I get a feel for LabVIEW's strengths and weaknesses -- Qt is a heavily event-driven framework (even for networking!), where polling often means you're doing something wrong.
Still, thank you for pointing out that I can use timeouts to determine if new data has arrived -- my subscriber current writes a null command back into the SV when it has consumed the command, but you showed me that I don't have to.