CPU

Titan employs 2 threads on the CPU during runtime: the user and the kernel threads. The user thread, as its name suggests, is the thread that remains available to the user program during runtime. The kernel thread ensures true parallelization between the user activity and the GPU by controlling the GPU and running kernels called on the user thread.

User Thread

The user thread runs code written by the user prior to the start of the simulation. Under normal conditions the user thread retains control of the majority of the CPU resources during runtime. This thread can be used to turn simple simulations into dynamic simulations whose characteristics change over time. Code in run by the user thread is unrestricted in its complexity and independent from the simulation unless otherwise specified. Several functions in Titan can be run in the user thread that retrieve information from the simulation or upload changes to it.

Specifically, user thread code may perform any of the following actions during a hot run:

• Retrieval of simulation data (getters)
• Modification of simulation data (setters)
• Independent CPU activity from Titan (i.e. data analysis)

Setters and getter functions meant to be run on the GPU are wrapper functions that send kernel call requests to the kernel thread of the CPU, which in turn calls the kernels asynchronously and handles communication between the user thread and the GPU.

Kernel Thread

The kernel thread's only function is to ensure parallel activity by communicating with the GPU periodically and calling any kernels needed to run the simulation. Once the simulation has been started, for example, the kernel thread calls the computeForces() continuously in time loop whose period is specified by the minimum mass time resolution found in the simulation. The need for this very specialized thread arises from the possibility of the user running intense activity during runtime (ie data analysis). Under a single treaded architecture, said activity would interfere with the simulation repeating kernel calls (necessary due to CUDA specifications), resulting in a discontinuous simulation timeline.

The low computation intensity and relative low frequency of kernel calling results in the kernel thread having very little impact on the total use of CPU resources.