All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Friends Macros Groups Pages
Thread Safety


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.
  • 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.

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

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.