As noted above, the library will fork a separate thread/process for each graphics pipe. This means that the application's display function may be called several times in parallel; the exact number of threads/processes varies depending on the configuration. But in some cases, an application developer may want to have the display function perform an action or calculation that should only be done by one process (such as diagnostic output or play an audio file). Because of this, the function CAVEMasterDisplay() returns true in exactly one display thread/process. A developer can use this function as a test to only enter a certain program section if indeed it is the master thread/process that has made the function call.
Because only a single thread/process may be doing this calculation, even if it is small, it may cause that thread/process to be slightly slower than the others. An undersirable effect would be if the master thread/process was updating a data variable that all display threads/processes needed to use. But since it takes some time to do the update, the non-master threads/processes may enter their rendering portion and use the data prior to it being updated for that frame. So sometimes it becomes necessary for an application developer to synchronize the display threads/processes if any data calculations are being done outside of the main process. The function CAVEDisplayBarrier() was created to cause the display threads/processes to block until all of them have called it. When using CAVEDisplayBarrier(), a developer needs to be sure that all the display processes call it, else the application will go into deadlock.