On 25/05/2004 at 5:05 PM, Scott Hannahs <[EMAIL PROTECTED]> wrote: > At 7:25 -0500 5/25/04, Geoffrey Schmit wrote: > >> 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.
In an attempt to address more directly your need to have non-blocking VIs in your GPIB library, I downloaded it last night. I also created a simple framework on Mac OS X that speaks the specified text. By doing both of these I now understand why the UI thread is being blocked during calls into your framework. First, some additional general comments: I'm not aware of a mechanism where you can call back into LabVIEW to allow other nodes to execute on your thread. However, since many of us have left Mac OS and moved to Mac OS X, a preemptive multi-threading operating system, this shouldn't be too restrictive. You may want to present those who use your library with both synchronous and asynchronous VIs since, for different applications, one may be more appropriate than another. Regardless, however, I would suggest that you make all your VIs as multi-threading-friendly as possible. Okay, on to the specifics. When I first examined the VIs in your library, I noticed that they were not marked as reentrant (VI properties -> Execute -> Reentrant Execution). I believed that this was required to ensure that other threads in LabVIEW continue to execute. However, when I created my simple framework to speak text, I experienced the same problem that you observed; the UI thread appeared to be blocked while the Call Library Node was executing calling into my framework. I then examined a DAQmx VI since I knew that these VIs didn't behave in this manner. At that point, I remembered that the function specified in the Call Library Node must be configured to be reentrant (change the popup menu next to the function name); not the VI itself. Once I made this change in my VI, the UI thread was no longer blocked. Hopefully, this information addresses your need to make your VIs non-blocking. Of course, when you specify that the function invoked by the Call Library Node is reentrant, you should ensure that it is safely reentrant. geoff -- Geoffrey Schmit Senior Software Engineer National Instruments [EMAIL PROTECTED] www.ni.com
