New Page 1

# Writing a Threaded Application

If you have a multiprocessor system, a multi-threaded application may be a good way to leverage your computing power.

The previous section described how one can implement parallel rendering for a cluster of PCs. It's often the case that applications are more easily parallelized on a shared memory symetric multiprocessor (SMP) system than a distributed memory system (a PC cluster). Also, some types of visualization tasks may make better use of memory if the dataset is shared by N threads within one process, rather than replicated across N systems in a cluster.

As a concrete example, suppose we have a 4-pipe SGI Onyx system. If we create four rendering threads we can render part of the scene with each of the four pipes and display a sort-last-composited image on the user's screen.

## The Threadtest demo

In `progs/threadtest/threadtest.c` you'll find an example of a threaded Chromium application. It's actually very similar to the psubmit demo.

The threadtest program accepts the following command line arguments:

- `-t numThreads` indicates how many threads to create. The default is one.
- `-w` specifies that a separate window should be created for each thread. The default is for all threads to render into one window.
- `-s1` specifies that only one thread should issue SwapBuffers commands. The default is for all threads to swap their windows.
- `-b` specifies that barriers should be used for synchronization.

The `threadtest.c` program is very similar to the `psubmit.c` program. The major difference is the addition of code to create the N rendering threads (using Windows threads or pthreads). Like `psubmit.c`, barriers are used after glClear and before SwapBuffers in order to provide synchronization.

`mothership/configs/threadtest.conf` is a sample configuration file for running the threadtest demo. This configuration file will pass the appropriate command line arguments to the threadtest program. It has several options to demonstrate various multi-threaded configurations. Look near the top of the file for these options:

- `NumThreads` indicates the number of threads to create
- `Config` can take one of four values: LOCAL_ONE_WINDOW, LOCAL_N_WINDOWS, REMOTE_ONE_WINDOW or SORT_LAST. These demonstrate different types of parallelism.

The LOCAL_ONE_WINDOW option will create one window which all N threads will render into in parallel. glClear and SwapBuffers are synchronized with barriers. There is no server node; just run the mothership and crappfaker.

The LOCAL_N_WINDOWS option will create one window which all N threads will render into in parallel. There is no server node; just run the mothership and crappfaker.

The REMOTE_ONE_WINDOW option uses a pack SPU to send N streams of rendering commands to a render SPU running on a server node. Run the mothership, a crserver and crappfaker.

The SORT_LAST option uses a readback SPU to render N partial images which are sent to render SPU on a downstream server. Run the mothership, a crserver and crappfaker. Note that we don't use the -b option since the readback SPU itself will implement barrier synchronization.

Threaded sort-first rendering with the tilesort SPU is also possible but is not implemented in the configuration script.

## Enabling Thread Safety in Chromium

Chromium is not thread-safe by default. To enable thread safety, edit the `options.mk` file, run `make clean` then run `make`.