Chapter 7 NI-488.2 Programming Techniques
© National Instruments Corporation 7-9 NI-488.2 User Manual for Windows
return 0;
}
else { return RQS;
}
}
}
Writing Multithreaded Win32 NI-488.2 ApplicationsIf you are writing a multithreaded NI-488.2 application and you plan to
make all of your NI-488.2 calls from a single thread, you can safely
continue to use the traditional NI-488.2 global variables (ibsta, iberr,
ibcnt, ibcntl). The NI-488.2 global variables are defined on a
per-process basis, so each process accesses its own copy of the NI-488.2
globals.
If you are writing a multithreaded NI-488.2 application and you plan to
make NI-488.2 calls from more than a single thread, you cannot safely
continue to use the traditional NI-488.2 global variables without some form
of synchronization (for example, a semaphore). To understand why, refer to
the following example.
Assume that a process has two separate threads that make NI-488.2 calls,
thread #1 and thread #2. Just as thread #1 is about to examine one of the
NI-488.2 globals, it gets preempted and thread #2 is allowed to run.
Thread #2 proceeds to make several NI-488.2 calls that automatically
update the NI-488.2 globals. Later, when thread #1 is allowed to run, the
NI-488.2 global that it is ready to examine is no longer in a known state
and it s value is no longer reliable.
The previous example illustrates a well-known multithreading problem.
Itis unsafe to access process-global variables from multiple threads of
execution. You can avoid this problem in two ways:
•Use synchronization to protect access to process-global variables.
•Do not use process-global variables.
If you choose to implement the synchronization solution, you must ensure
that the code making NI-488.2 calls and examining the NI-488.2 globals
modified by a NI-488.2 call is protected by a synchronization primitive. For
example, each thread might acquire a semaphore before making a NI-488.2
call and then release the semaphore after examining the NI-488.2 globals