At 7:25 -0500 5/25/04, Geoffrey Schmit wrote: >For example, I'm >not sure what you mean by a "LV style" wait. I'm not aware of a >construct that would allow a thread to wait on a synchronization >primitive and yet continue to execute. That is, a thread is either >running or waiting. If my definition of an asynchronous call matches >your definition of a "LV style" wait, great. If not, please let me know >what you have in mind.
Yep. Just like the "Wait (ms)" node within LV. If that could be called (sort of a cooperative multi-tasking) from a CIN then you could make non-blocking CIN or Shared libraries. >Most VIs, including the DAQmx >Read VI, operate in this fashion. Good to know, I am not familiar with the new "mx" stuff and thought it may be different. >These two types of calls present fundamentally different API models. In >general, synchronous calls cannot simply be converted to asynchronous >calls without changing the semantics of the API and adding additional >concepts (e.g., call backs, query calls). Ok. I was thinking along the lines of Asynchronous/Synchronous VISA read and write calls that can be switched from synchronous to asynchronous with a pop-up menu selection. I realize that the underlying calls might be different but they present the same wrapper. >However, if the thread waits on a >synchronization primitive, other threads will not be competing with this >thread until this synchronization primitive is signaled and the thread >is awakened. This is why I may make my labview calls do a wait for occurrence and pass the occurrence to the library in a reentrant call. The library can signal the occurrence eventually and thus there is a no penalty wait for I/O to complete. >However, a >call that acquires a more specific lock (e.g., DAQmx VIs that acquire a >lock for a specific task) will only prevent other threads that try to >acquire that specific lock from executing. So DAQmx has threading and locks at a much finer (task) level rather than the whole DAQ system. >While I'm certainly not an NI-488.2 expert, I believe there are both >synchronous and asynchronous functions in NI-488.2. Not in the 488.2 spec but in the C library and/or the driver and at the VISA call level. The problem is that there is NO NI-488.2 for OS X (at the moment). So I am developing sth-488.2 based on the incomplete 488.2 DDK toolkit that NI provides. The trick is how to move that asynchronous call in the library (when I get it implemented) into the synchronous nature of a LabVIEW call into a library. > Regardless, other >threads in your application should be able to execute while a NI-488.2 >call is waiting subject to the restrictions I've mentioned. If there were such a thing as an NI-488.2 call! I need to implement that asynchronous call not merely use it. > If you're >concerned that your PCI-GPIB library is too inefficient when waiting and >it is polling, maybe you can change its implementation such that the >thread waits on a synchronization object rather than polls (or at least >occasionally yields to give other threads more of a chance to use the >processor). How do I yield from a C program back to the labview program? It may allow the other threads to run automatically but it blocks the UI thread I think and that is really a significant block > If you're concerned that other threads in your application >cannot execute because the thread that is waiting has acquired a common >lock, perhaps the lock can be eliminated or a finer-grained lock can be >used instead. But I can't change the basic locking mechanism of the Labview execution system... Or if I can, I think I would get a big warning message "Rusty Nails Ahead!". I think Jason also expressed my problem quite well and outlined the difference between what we can access as a LabVIEW programmer vs. what I get if I dust of my old C programming hat. > > Presumably you are more of a DAQ-centric person than a LabVIEW-centric > > person at NI. >I'm more of an operating-system-centric person at NI :) NI is developing a new OS?! LabVIEW everywhere indeed! :-) Cheers, Scott
