WiFi is the physical layer, or at least the lower layer(s) of the inter-computer network.
At the application layer, where you CVI app exists, it seems likely that you wouldn't deal with the WiFi so much as with a TCP connection, or some inter-process communications (IPC) mechanism, e.g. a named pipe.
I have solved a similar problem over a LAN (ethernet, not WiFi) using named pipes. I'm guessing you're running a Windows OS? If so, you can set up named pipes from the control or master PC to each of the client or slave PC's, then when it's time to start, send a message from the master to each of the slave PC's to collect data.
You could have the application on each slave start up and then hang a read on the named pipe and be waiting for the message so as to quickly react.
As far as latency / synchronization, you may have a problem there - getting a relativley fast (9 msec) deterministic, synchronoous response across a LAN (WiFi or not) is going to be problematic I would say.
I've also implemented multi-PC systems where we used a simple DC voltage as a trigger between systems, but I wouldn't bet that it worked within 9 msec.
For distributed, concurrent sensor readings a traditional mechanism is to route an electrical trigger to the sensors, as with a scope trigger, and thereby keep any computing out of the loop.