This thesis describes the technological, application and scientific issues involved in the design of environments for the purpose of interactive exploration in virtual environments

Robert Gerardus Belleman

Belleman, R.G.

Search4Dev

UvA-DARE is a service provided by the library of the University of Amsterdam (http://dare.uva.nl)
UvA-DARE (Digital Academic Repository)
Interactive Exploration in Virtual Environments
Belleman, R.G.
Link to publication
Citation for published version (APA):
Belleman, R. G. (2003). Interactive Exploration in Virtual Environments.
General rights
It is not permitted to download or to forward/distribute the text or part of it without the consent of the author(s) and/or copyright holder(s),
other than for strictly personal, individual use, unless the work is under an open content license (like Creative Commons).
Disclaimer/Complaints regulations
If you believe that digital publication of certain material infringes any of your rights or (privacy) interests, please let the Library know, stating
your reasons. In case of a legitimate complaint, the Library will make the material inaccessible and/or remove it from the website. Please Ask
the Library: https://uba.uva.nl/en/contact, or a letter to: Library of the University of Amsterdam, Secretariat, Singel 425, 1012 WP Amsterdam,
The Netherlands. You will be contacted as soon as possible.
Download date: 08 Feb 2021
Appendixx A 
Thee CAVE librar y 
Thee CAVE Library (CAVELib) is a set of libraries designed as a base for developing 
virtuall  reality applications for spatially immersive displays [249]. CAVELib has been 
inn development since the debut of the CAVE in 1992, and is widely used in research 
andd academic areas. CAVELib abstracts from the hardware used in a VR device and 
thereforee allows portable VE applications to be built. The operating systems on which 
CAVELibb is supported is currently IRLX, Linux, Solaris, HPUX and Microsoft Win-
dows.. The graphics interfaces supported by CAVELib are OpenGL and Performer. 
AA schematic diagram of a CAVELib application is shown in Figure A.l . CAVELib 
forkss separate processes for each display (i.e. each wall). Communication between 
processess is done through shared memory which implies that semaphore locking op-
eratorss are required to enforce mutual exclusion to shared data structures and to 
synchronizee processes. The states of the trackers and controllers are also stored in 
sharedd memory. This tracker data is acquired from the hardware through a sepa-
ratee daemon proces known as t rackd. Several library functions are provided by 
CAVELibb to acces this data. Each display proces is synchronized and automatically 
renderss the correct perspective for each wall. Flexible configuration files make pro-
gramss written with CAVELib portable to several display and input devices without 
thee need to recompile. The library also provides functions to share information on 
aa virtual environment over a network. This allows users on geographically different 
locationss to collaborate in the same virtual environment. 
A.11 Interprocess communication in a CAVELi b ap-
plication n 
Afterr initialization, CAVELib applications spawn multiple processes; one "master pro-
cess""  that handles user input and performs the necessary calculations that define the 
behaviourr of the virtual environment and one or more "display processes" that do the 
rendering,, one proces for each wall. From a software design standpoint the master 
proces s describes the proces under investigation by fillin g in (writing) a data struc-
turee that is used (read) by the display processes for representation. Conceptually this 
142 2 TheThe CAVE library 
CAVEInitQ Q 
Forkk a proces for 
eachh display 
Calll user's frame 
updatee function 
Calll user's frame 
updatee function 
Calll user's frame 
updatee function 
Setupp for left eye 
Calll user's graphics function 
Setupp for right eye 
Calll user's graphics function 
Setupp for left eye 
Calll user's graphics function 
Setupp for left eye 
Calll users graphics function 
Setupp for right eye 
Calll user's graphics function 
Setupp for right eye 
Calll user's graphics function 
Barrierr - Wait for all display processes to finish rendering left/right eyes 
Swapp buffers 
Updatee CAVELib 
sharedd variables 
(thiss is the master process) 
Swapp buffers 
Barrierr - Wait for master process to finish updating shared variables 
FigureFigure A.l: Flowchart of a CAVELib program [249]. 
usee of a shared data structure ("shared" in the sense that changes made by one pro-
cesss wil l also be available to other processes) is an easy to understand and sensible 
programm structure to have two processes intercommunicate. Unfortunately, a design 
choicee in CAVELib makes this a littl e harder than it should be. 
Thee processes created by CAVELib are spawned using the fork () system call which 
meanss that, at least initially , each proces is the same except for its proces identifier 
andd parent proces identifier. Most UNIX operating systems optimize the creation 
off  new processes by fork () by a "copy-on-write" mechanism [232]. This mechanism 
allowss the kernel to create the processes in such a way that they can execute from 
thee same memory areas as long as the processes perform only read accesses to this 
memory.. When a proces attempts a write access, the kernel first copies the memory 
areass before the proces is allowed to continue. The implication of this for CAVELib 
applicationss is that the "shared" data structure proposed in the previous section wil l 
inn practice not be shared between the processes at all. Instead, the main proces 
A.lA.l Interprocess communication in a CAVELib application 143 
wil ll  have its own private copy from the moment it first writes to it while the display 
processess are reading from the initial, unchanged version. 
Thee proposed method in CAVELib applications for solving this is through the use of 
"sharedd memory". As the name suggests, shared memory allows two or more pro-
cessess to share a given region of memory [226]. A CAVELib application would, before 
anyy processes are spawned, allocate an area of shared memory and then pass a ref-
erencee to this area to all processes that need acces to it. While the main proces 
iss writing in the area, semaphores are used to prevent the display processes from 
accessingg the area until the main proces is done. The use of shared memory is a 
perfectlyy acceptable method for interproces communications. However, shared mem-
oryy is a restricted resource in some UNIX kernels. For example; on IRIX systems the 
maximumm amount of shared memory is 4 GB but in most Linux kernels the maxi-
mumm is set to 32 MB by default. While 4 GB of shared memory is sufficient for most 
CAVELibb applications, the amount of 32 MB is quickly depleted as applications grow 
moree complex. 
Anotherr reason why interproces communication via shared memory is cumbersome 
iss in the overhead that is caused when data needs to be copied from heap (i.e., "nor-
mal")) memory to shared memory. This can occur when, for example, the main proces 
usess external, third-party libraries to prepare data for rendering that return the out-
putt into heap memory (as most libraries do if they use the standard n.al loc ( > family 
off  functions or the C++ new operator). Since the display processes wil l not be able to 
access this memory without causing a memory violation, the main proces wil l have 
too copy this data into shared memory. The overhead caused by this, both in terms 
off  the length of time needed to copy as well as the additional memory needed for 
thee copy, can dramatically influence application performance, especially in dynamic 
applicationss where the data that is to be rendered changes frequently. 
Ann easier solution to solve these problems would be if CAVELib spawned threads 
insteadd of processes [130], The main difference between processes and threads is that 
threadss share (most of) the resources with its parent process. This allows threads to 
access memory areas concurrently with its parent proces and other threads without 
thee side effects described above. VRCO apparently realized this themselves as since 
versionn 3.0 (which was in beta at the beginning of 2002") CAVELib provides an option 
too spawn the different processes as threads instead of processes. 
Thankss to Matt Szvmanski (VRCO) for allowing me to test a Linux beta version of'a multi-threaded 
CAVELib. . 
1444 The CAVE library 


English

Interactive Exploration in Virtual Environments

UvA-DARE

NARCIS 

International Migration, Integration and Social Cohesion online publications

UvA-DARE is a service provided by the library of the University of Amsterdam (http://dare.uva.nl)
UvA-DARE (Digital Academic Repository)
Interactive Exploration in Virtual Environments
Belleman, R.G.
Link to publication
Citation for published version (APA):
Belleman, R. G. (2003). Interactive Exploration in Virtual Environments.
General rights
It is not permitted to download or to forward/distribute the text or part of it without the consent of the author(s) and/or copyright holder(s),
other than for strictly personal, individual use, unless the work is under an open content license (like Creative Commons).
Disclaimer/Complaints regulations
If you believe that digital publication of certain material infringes any of your rights or (privacy) interests, please let the Library know, stating
your reasons. In case of a legitimate complaint, the Library will make the material inaccessible and/or remove it from the website. Please Ask
the Library: https://uba.uva.nl/en/contact, or a letter to: Library of the University of Amsterdam, Secretariat, Singel 425, 1012 WP Amsterdam,
The Netherlands. You will be contacted as soon as possible.
Download date: 04 Feb 2021
Appendixx A 
Thee CAVE librar y 
Thee CAVE Library (CAVELib) is a set of libraries designed as a base for developing 
virtuall  reality applications for spatially immersive displays [249]. CAVELib has been 
inn development since the debut of the CAVE in 1992, and is widely used in research 
andd academic areas. CAVELib abstracts from the hardware used in a VR device and 
thereforee allows portable VE applications to be built. The operating systems on which 
CAVELibb is supported is currently IRLX, Linux, Solaris, HPUX and Microsoft Win-
dows.. The graphics interfaces supported by CAVELib are OpenGL and Performer. 
AA schematic diagram of a CAVELib application is shown in Figure A.l . CAVELib 
forkss separate processes for each display (i.e. each wall). Communication between 
processess is done through shared memory which implies that semaphore locking op-
eratorss are required to enforce mutual exclusion to shared data structures and to 
synchronizee processes. The states of the trackers and controllers are also stored in 
sharedd memory. This tracker data is acquired from the hardware through a sepa-
ratee daemon proces known as t rackd. Several library functions are provided by 
CAVELibb to acces this data. Each display proces is synchronized and automatically 
renderss the correct perspective for each wall. Flexible configuration files make pro-
gramss written with CAVELib portable to several display and input devices without 
thee need to recompile. The library also provides functions to share information on 
aa virtual environment over a network. This allows users on geographically different 
locationss to collaborate in the same virtual environment. 
A.11 Interprocess communication in a CAVELi b ap-
plication n 
Afterr initialization, CAVELib applications spawn multiple processes; one "master pro-
cess""  that handles user input and performs the necessary calculations that define the 
behaviourr of the virtual environment and one or more "display processes" that do the 
rendering,, one proces for each wall. From a software design standpoint the master 
proces s describes the proces under investigation by fillin g in (writing) a data struc-
turee that is used (read) by the display processes for representation. Conceptually this 
142 2 TheThe CAVE library 
CAVEInitQ Q 
Forkk a proces for 
eachh display 
Calll user's frame 
updatee function 
Calll user's frame 
updatee function 
Calll user's frame 
updatee function 
Setupp for left eye 
Calll user's graphics function 
Setupp for right eye 
Calll user's graphics function 
Setupp for left eye 
Calll user's graphics function 
Setupp for left eye 
Calll users graphics function 
Setupp for right eye 
Calll user's graphics function 
Setupp for right eye 
Calll user's graphics function 
Barrierr - Wait for all display processes to finish rendering left/right eyes 
Swapp buffers 
Updatee CAVELib 
sharedd variables 
(thiss is the master process) 
Swapp buffers 
Barrierr - Wait for master process to finish updating shared variables 
FigureFigure A.l: Flowchart of a CAVELib program [249]. 
usee of a shared data structure ("shared" in the sense that changes made by one pro-
cesss wil l also be available to other processes) is an easy to understand and sensible 
programm structure to have two processes intercommunicate. Unfortunately, a design 
choicee in CAVELib makes this a littl e harder than it should be. 
Thee processes created by CAVELib are spawned using the fork () system call which 
meanss that, at least initially , each proces is the same except for its proces identifier 
andd parent proces identifier. Most UNIX operating systems optimize the creation 
off  new processes by fork () by a "copy-on-write" mechanism [232]. This mechanism 
allowss the kernel to create the processes in such a way that they can execute from 
thee same memory areas as long as the processes perform only read accesses to this 
memory.. When a proces attempts a write access, the kernel first copies the memory 
areass before the proces is allowed to continue. The implication of this for CAVELib 
applicationss is that the "shared" data structure proposed in the previous section wil l 
inn practice not be shared between the processes at all. Instead, the main proces 
A.lA.l Interprocess communication in a CAVELib application 143 
wil ll  have its own private copy from the moment it first writes to it while the display 
processess are reading from the initial, unchanged version. 
Thee proposed method in CAVELib applications for solving this is through the use of 
"sharedd memory". As the name suggests, shared memory allows two or more pro-
cessess to share a given region of memory [226]. A CAVELib application would, before 
anyy processes are spawned, allocate an area of shared memory and then pass a ref-
erencee to this area to all processes that need acces to it. While the main proces 
iss writing in the area, semaphores are used to prevent the display processes from 
accessingg the area until the main proces is done. The use of shared memory is a 
perfectlyy acceptable method for interproces communications. However, shared mem-
oryy is a restricted resource in some UNIX kernels. For example; on IRIX systems the 
maximumm amount of shared memory is 4 GB but in most Linux kernels the maxi-
mumm is set to 32 MB by default. While 4 GB of shared memory is sufficient for most 
CAVELibb applications, the amount of 32 MB is quickly depleted as applications grow 
moree complex. 
Anotherr reason why interproces communication via shared memory is cumbersome 
iss in the overhead that is caused when data needs to be copied from heap (i.e., "nor-
mal")) memory to shared memory. This can occur when, for example, the main proces 
usess external, third-party libraries to prepare data for rendering that return the out-
putt into heap memory (as most libraries do if they use the standard n.al loc ( > family 
off  functions or the C++ new operator). Since the display processes wil l not be able to 
access this memory without causing a memory violation, the main proces wil l have 
too copy this data into shared memory. The overhead caused by this, both in terms 
off  the length of time needed to copy as well as the additional memory needed for 
thee copy, can dramatically influence application performance, especially in dynamic 
applicationss where the data that is to be rendered changes frequently. 
Ann easier solution to solve these problems would be if CAVELib spawned threads 
insteadd of processes [130], The main difference between processes and threads is that 
threadss share (most of) the resources with its parent process. This allows threads to 
access memory areas concurrently with its parent proces and other threads without 
thee side effects described above. VRCO apparently realized this themselves as since 
versionn 3.0 (which was in beta at the beginning of 2002") CAVELib provides an option 
too spawn the different processes as threads instead of processes. 
Thankss to Matt Szvmanski (VRCO) for allowing me to test a Linux beta version of'a multi-threaded 
CAVELib. . 
1444 The CAVE library 


UvA-DARE is a service provided by the library of the University of Amsterdam (https://dare.uva.nl)UvA-DARE (Digital Academic Repository)Interactive Exploration in Virtual EnvironmentsBelleman, R.G.Publication date2003Link to publicationCitation for published version (APA):Belleman, R. G. (2003). Interactive Exploration in Virtual Environments. [Thesis, fully internal,Universiteit van Amsterdam].General rightsIt is not permitted to download or to forward/distribute the text or part of it without the consent of the author(s)and/or copyright holder(s), other than for strictly personal, individual use, unless the work is under an opencontent license (like Creative Commons).Disclaimer/Complaints regulationsIf you believe that digital publication of certain material infringes any of your rights or (privacy) interests, pleaselet the Library know, stating your reasons. In case of a legitimate complaint, the Library will make the materialinaccessible and/or remove it from the website. Please Ask the Library: https://uba.uva.nl/en/contact, or a letterto: Library of the University of Amsterdam, Secretariat, Singel 425, 1012 WP Amsterdam, The Netherlands. Youwill be contacted as soon as possible.Download date:15 Apr 2023Appendixx A Thee CAVE librar y Thee CAVE Library (CAVELib) is a set of libraries designed as a base for developing virtuall  reality applications for spatially immersive displays [249]. CAVELib has been inn development since the debut of the CAVE in 1992, and is widely used in research andd academic areas. CAVELib abstracts from the hardware used in a VR device and thereforee allows portable VE applications to be built. The operating systems on which CAVELibb is supported is currently IRLX, Linux, Solaris, HPUX and Microsoft Win-dows.. The graphics interfaces supported by CAVELib are OpenGL and Performer. AA schematic diagram of a CAVELib application is shown in Figure A.l . CAVELib forkss separate processes for each display (i.e. each wall). Communication between processess is done through shared memory which implies that semaphore locking op-eratorss are required to enforce mutual exclusion to shared data structures and to synchronizee processes. The states of the trackers and controllers are also stored in sharedd memory. This tracker data is acquired from the hardware through a sepa-ratee daemon proces known as t rackd. Several library functions are provided by CAVELibb to acces this data. Each display proces is synchronized and automatically renderss the correct perspective for each wall. Flexible configuration files make pro-gramss written with CAVELib portable to several display and input devices without thee need to recompile. The library also provides functions to share information on aa virtual environment over a network. This allows users on geographically different locationss to collaborate in the same virtual environment. A.11 Interprocess communication in a CAVELi b ap-plication n Afterr initialization, CAVELib applications spawn multiple processes; one "master pro-cess""  that handles user input and performs the necessary calculations that define the behaviourr of the virtual environment and one or more "display processes" that do the rendering,, one proces for each wall. From a software design standpoint the master proces s describes the proces under investigation by fillin g in (writing) a data struc-turee that is used (read) by the display processes for representation. Conceptually this 142 2 TheThe CAVE library CAVEInitQ Q Forkk a proces for eachh display Calll user's frame updatee function Calll user's frame updatee function Calll user's frame updatee function Setupp for left eye Calll user's graphics function Setupp for right eye Calll user's graphics function Setupp for left eye Calll user's graphics function Setupp for left eye Calll users graphics function Setupp for right eye Calll user's graphics function Setupp for right eye Calll user's graphics function Barrierr - Wait for all display processes to finish rendering left/right eyes Swapp buffers Updatee CAVELib sharedd variables (thiss is the master process) Swapp buffers Barrierr - Wait for master process to finish updating shared variables FigureFigure A.l: Flowchart of a CAVELib program [249]. usee of a shared data structure ("shared" in the sense that changes made by one pro-cesss wil l also be available to other processes) is an easy to understand and sensible programm structure to have two processes intercommunicate. Unfortunately, a design choicee in CAVELib makes this a littl e harder than it should be. Thee processes created by CAVELib are spawned using the fork () system call which meanss that, at least initially , each proces is the same except for its proces identifier andd parent proces identifier. Most UNIX operating systems optimize the creation off  new processes by fork () by a "copy-on-write" mechanism [232]. This mechanism allowss the kernel to create the processes in such a way that they can execute from thee same memory areas as long as the processes perform only read accesses to this memory.. When a proces attempts a write access, the kernel first copies the memory areass before the proces is allowed to continue. The implication of this for CAVELib applicationss is that the "shared" data structure proposed in the previous section wil l inn practice not be shared between the processes at all. Instead, the main proces A.lA.l Interprocess communication in a CAVELib application 143 wil ll  have its own private copy from the moment it first writes to it while the display processess are reading from the initial, unchanged version. Thee proposed method in CAVELib applications for solving this is through the use of "sharedd memory". As the name suggests, shared memory allows two or more pro-cessess to share a given region of memory [226]. A CAVELib application would, before anyy processes are spawned, allocate an area of shared memory and then pass a ref-erencee to this area to all processes that need acces to it. While the main proces iss writing in the area, semaphores are used to prevent the display processes from accessingg the area until the main proces is done. The use of shared memory is a perfectlyy acceptable method for interproces communications. However, shared mem-oryy is a restricted resource in some UNIX kernels. For example; on IRIX systems the maximumm amount of shared memory is 4 GB but in most Linux kernels the maxi-mumm is set to 32 MB by default. While 4 GB of shared memory is sufficient for most CAVELibb applications, the amount of 32 MB is quickly depleted as applications grow moree complex. Anotherr reason why interproces communication via shared memory is cumbersome iss in the overhead that is caused when data needs to be copied from heap (i.e., "nor-mal")) memory to shared memory. This can occur when, for example, the main proces usess external, third-party libraries to prepare data for rendering that return the out-putt into heap memory (as most libraries do if they use the standard n.al loc ( > family off  functions or the C++ new operator). Since the display processes wil l not be able to access this memory without causing a memory violation, the main proces wil l have too copy this data into shared memory. The overhead caused by this, both in terms off  the length of time needed to copy as well as the additional memory needed for thee copy, can dramatically influence application performance, especially in dynamic applicationss where the data that is to be rendered changes frequently. Ann easier solution to solve these problems would be if CAVELib spawned threads insteadd of processes [130], The main difference between processes and threads is that threadss share (most of) the resources with its parent process. This allows threads to access memory areas concurrently with its parent proces and other threads without thee side effects described above. VRCO apparently realized this themselves as since versionn 3.0 (which was in beta at the beginning of 2002") CAVELib provides an option too spawn the different processes as threads instead of processes. Thankss to Matt Szvmanski (VRCO) for allowing me to test a Linux beta version of'a multi-threaded CAVELib. . 1444 The CAVE library 

CiteSeerX

UvA-DARE is a service provided by the library of the University of Amsterdam (https://dare.uva.nl)UvA-DARE (Digital Academic Repository)Interactive Exploration in Virtual EnvironmentsBelleman, R.G.Publication date2003Link to publicationCitation for published version (APA):Belleman, R. G. (2003). Interactive Exploration in Virtual Environments.General rightsIt is not permitted to download or to forward/distribute the text or part of it without the consent of the author(s)and/or copyright holder(s), other than for strictly personal, individual use, unless the work is under an opencontent license (like Creative Commons).Disclaimer/Complaints regulationsIf you believe that digital publication of certain material infringes any of your rights or (privacy) interests, pleaselet the Library know, stating your reasons. In case of a legitimate complaint, the Library will make the materialinaccessible and/or remove it from the website. Please Ask the Library: https://uba.uva.nl/en/contact, or a letterto: Library of the University of Amsterdam, Secretariat, Singel 425, 1012 WP Amsterdam, The Netherlands. Youwill be contacted as soon as possible.Download date:27 Jul 2022Appendixx A Thee CAVE librar y Thee CAVE Library (CAVELib) is a set of libraries designed as a base for developing virtuall  reality applications for spatially immersive displays [249]. CAVELib has been inn development since the debut of the CAVE in 1992, and is widely used in research andd academic areas. CAVELib abstracts from the hardware used in a VR device and thereforee allows portable VE applications to be built. The operating systems on which CAVELibb is supported is currently IRLX, Linux, Solaris, HPUX and Microsoft Win-dows.. The graphics interfaces supported by CAVELib are OpenGL and Performer. AA schematic diagram of a CAVELib application is shown in Figure A.l . CAVELib forkss separate processes for each display (i.e. each wall). Communication between processess is done through shared memory which implies that semaphore locking op-eratorss are required to enforce mutual exclusion to shared data structures and to synchronizee processes. The states of the trackers and controllers are also stored in sharedd memory. This tracker data is acquired from the hardware through a sepa-ratee daemon proces known as t rackd. Several library functions are provided by CAVELibb to acces this data. Each display proces is synchronized and automatically renderss the correct perspective for each wall. Flexible configuration files make pro-gramss written with CAVELib portable to several display and input devices without thee need to recompile. The library also provides functions to share information on aa virtual environment over a network. This allows users on geographically different locationss to collaborate in the same virtual environment. A.11 Interprocess communication in a CAVELi b ap-plication n Afterr initialization, CAVELib applications spawn multiple processes; one "master pro-cess""  that handles user input and performs the necessary calculations that define the behaviourr of the virtual environment and one or more "display processes" that do the rendering,, one proces for each wall. From a software design standpoint the master proces s describes the proces under investigation by fillin g in (writing) a data struc-turee that is used (read) by the display processes for representation. Conceptually this 142 2 TheThe CAVE library CAVEInitQ Q Forkk a proces for eachh display Calll user's frame updatee function Calll user's frame updatee function Calll user's frame updatee function Setupp for left eye Calll user's graphics function Setupp for right eye Calll user's graphics function Setupp for left eye Calll user's graphics function Setupp for left eye Calll users graphics function Setupp for right eye Calll user's graphics function Setupp for right eye Calll user's graphics function Barrierr - Wait for all display processes to finish rendering left/right eyes Swapp buffers Updatee CAVELib sharedd variables (thiss is the master process) Swapp buffers Barrierr - Wait for master process to finish updating shared variables FigureFigure A.l: Flowchart of a CAVELib program [249]. usee of a shared data structure ("shared" in the sense that changes made by one pro-cesss wil l also be available to other processes) is an easy to understand and sensible programm structure to have two processes intercommunicate. Unfortunately, a design choicee in CAVELib makes this a littl e harder than it should be. Thee processes created by CAVELib are spawned using the fork () system call which meanss that, at least initially , each proces is the same except for its proces identifier andd parent proces identifier. Most UNIX operating systems optimize the creation off  new processes by fork () by a "copy-on-write" mechanism [232]. This mechanism allowss the kernel to create the processes in such a way that they can execute from thee same memory areas as long as the processes perform only read accesses to this memory.. When a proces attempts a write access, the kernel first copies the memory areass before the proces is allowed to continue. The implication of this for CAVELib applicationss is that the "shared" data structure proposed in the previous section wil l inn practice not be shared between the processes at all. Instead, the main proces A.lA.l Interprocess communication in a CAVELib application 143 wil ll  have its own private copy from the moment it first writes to it while the display processess are reading from the initial, unchanged version. Thee proposed method in CAVELib applications for solving this is through the use of "sharedd memory". As the name suggests, shared memory allows two or more pro-cessess to share a given region of memory [226]. A CAVELib application would, before anyy processes are spawned, allocate an area of shared memory and then pass a ref-erencee to this area to all processes that need acces to it. While the main proces iss writing in the area, semaphores are used to prevent the display processes from accessingg the area until the main proces is done. The use of shared memory is a perfectlyy acceptable method for interproces communications. However, shared mem-oryy is a restricted resource in some UNIX kernels. For example; on IRIX systems the maximumm amount of shared memory is 4 GB but in most Linux kernels the maxi-mumm is set to 32 MB by default. While 4 GB of shared memory is sufficient for most CAVELibb applications, the amount of 32 MB is quickly depleted as applications grow moree complex. Anotherr reason why interproces communication via shared memory is cumbersome iss in the overhead that is caused when data needs to be copied from heap (i.e., "nor-mal")) memory to shared memory. This can occur when, for example, the main proces usess external, third-party libraries to prepare data for rendering that return the out-putt into heap memory (as most libraries do if they use the standard n.al loc ( > family off  functions or the C++ new operator). Since the display processes wil l not be able to access this memory without causing a memory violation, the main proces wil l have too copy this data into shared memory. The overhead caused by this, both in terms off  the length of time needed to copy as well as the additional memory needed for thee copy, can dramatically influence application performance, especially in dynamic applicationss where the data that is to be rendered changes frequently. Ann easier solution to solve these problems would be if CAVELib spawned threads insteadd of processes [130], The main difference between processes and threads is that threadss share (most of) the resources with its parent process. This allows threads to access memory areas concurrently with its parent proces and other threads without thee side effects described above. VRCO apparently realized this themselves as since versionn 3.0 (which was in beta at the beginning of 2002") CAVELib provides an option too spawn the different processes as threads instead of processes. Thankss to Matt Szvmanski (VRCO) for allowing me to test a Linux beta version of'a multi-threaded CAVELib. . 1444 The CAVE library 

Interactive Exploration in Virtual Environments

Abstract

Similar works

Full text

Available Versions

Search4Dev

UvA-DARE

NARCIS

International Migration, Integration and Social Cohesion online publications

International Migration, Integration and Social Cohesion online publications

CiteSeerX

International Migration, Integration and Social Cohesion online publications