Thread Safety

General

When operating in multiple threads it is important that data structures manipulated by one thread don't cause another thread to crash.

Calling into Houdini functions can often be non-threadsafe, especially if those functions access shared data structures or can have unknown effects. The following functions are dangerous.

• Evaluating parameters or nodes (see section below).
• Modifying parameters or node data while evaluating them.
• Adding/removing points, attributes, primitives, on a GU_Detail while another thread access the same GU_Detail.
• SIM_DATA_GET in DOPs.
• Creating UT_VoxelArrayWriteHandle for the same GEO_PrimVolume in multiple threads. Instead, create it outside and pass UT_VoxelArray down, butnote the tile restriction.

Some things are safe in multiple threads.

• UT_VoxelArray, an instance of Volumes in Houdini, can be read from by many threads.
• UT_VoxelArray can be written to by multiple threads provided different sub-tiles (see Volumes in Houdini) are written to. The UT_VoxelArrayIterator can be used to ensure this requirement is met. Note that while writing in this fashion, you cannot read from other tiles of the same UT_VoxelArray
• GU_Detail's GEO_Point can be manipulated provided overlapping points are not specified.

If you need to protect your own data structures from being accessed by multiple threads you can use a lock object (eg. UT_Lock). The best way to lock and unlock is by using the corresponding nested Scope class (eg. UT_Lock::Scope). If the work you do inside an acquired lock might result in the lock being reacquired in a child thread, then use UT_TaskLock instead of UT_Lock. If the work inside the acquired lock might run into deadlocks, then use UT_AbortableRecursiveLock, or UT_AbortableTaskLock.

If you have a singleton you want to ensure is only created once and shared across threads consider using UT_DoubleLock.

See Also

• Multithreading Classes
• Creating Child Threads

Evaluating parameters and nodes

Houdini parameter and node evaluation is currently not threadsafe. This means that performing parameter and node evaluation from multiple threads is not safe unless it is guarded by an EXPR_GlobalStaticLock::Scope object.