Chapter 7 NI-488.2 Programming Techniques© National Instruments Corporation 7-9 NI-488.2 User Manual for Windowsreturn 0;}else {return RQS;}}}Writing Multithreaded Win32 NI-488.2 ApplicationsIf you are writing a multithreaded NI-488.2 application and you plan tomake all of your NI-488.2 calls from a single thread, you can safelycontinue to use the traditional NI-488.2 global variables (ibsta, iberr,ibcnt, ibcntl). The NI-488.2 global variables are defined on aper-process basis, so each process accesses its own copy of the NI-488.2globals.If you are writing a multithreaded NI-488.2 application and you plan tomake NI-488.2 calls from more than a single thread, you cannot safelycontinue to use the traditional NI-488.2 global variables without some formof synchronization (for example, a semaphore). To understand why, refer tothe 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 theNI-488.2 globals, it gets preempted and thread #2 is allowed to run.Thread #2 proceeds to make several NI-488.2 calls that automaticallyupdate the NI-488.2 globals. Later, when thread #1 is allowed to run, theNI-488.2 global that it is ready to examine is no longer in a known stateand its value is no longer reliable.The previous example illustrates a well-known multithreading problem.It is unsafe to access process-global variables from multiple threads ofexecution. 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 ensurethat the code making NI-488.2 calls and examining the NI-488.2 globalsmodified by a NI-488.2 call is protected by a synchronization primitive. Forexample, each thread might acquire a semaphore before making a NI-488.2call and then release the semaphore after examining the NI-488.2 globals