Multi-Threading System
The HoloMIT SDK integrates a robust multi-threading system that allows developers to build high-performance and scalable XR applications by delegating heavy workloads away from Unity’s main thread. This system is designed with modularity, safety, and extensibility in mind.
Why Use Multi-threading in HoloMIT?
Unity's main thread is often overloaded with rendering, input, and game logic. To avoid performance bottlenecks and ensure smooth frame rates — especially in XR applications — HoloMIT offloads operations such as:
- Volumetric reconstruction
- Network communication
- Media compression and decoding
- Data buffering and queuing
System Components Overview
The multi-threading system consists of two main building blocks:
1. 🛠️ Workers
Workers are long-lived background threads derived from the BaseWorker class. They allow for recurring logic to run independently from Unity’s main loop.
Key features:
- Simple inheritance model
- Override
Update()for looped threaded logic - Clean lifecycle management with
Start(),Stop(),OnStop() - Designed following SOLID principles
📄 See full documentation: Workers
2. 📦 Thread-Safe Queues
Queues allow safe and synchronized communication between threads. For example, a capture worker may enqueue video frames for a distributor or renderer to consume.
Key features:
- Bounded, blocking or non-blocking behavior
- Supports producer-consumer threading models
- Automatic cleanup and shutdown handling
- Includes timestamp access and monitoring methods
📄 See full documentation: Thread-Safe Queues
Typical Use Case
A common real-world pattern:
[CaptureWorker] --> [QueueThreadSafe] --> [EncoderWorker] --> [QueueThreadSafe] --> [WriterWorker]
- Each stage is handled in a separate thread.
- Communication happens via thread-safe queues.
- Each worker can be independently started, monitored, and shut down.
Configuration Best Practices
| Task | Recommendation |
|---|---|
| Fast operations | Keep inside Update() with minimal blocking |
| Unity object access | Only from main thread – use events or queues |
| Shutdown handling | Always call StopAndWait() and queue.Close() |
| Monitoring | Use logging and _Count / _CanDequeue() to inspect queue states |
| Buffer sizing | Tune queue size based on system throughput |