thread_safe_apis.rst 4.9 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128
  1. .. _doc_thread_safe_apis:
  2. Thread-safe APIs
  3. ================
  4. Threads
  5. -------
  6. Threads are used to balance processing power across CPUs and cores.
  7. Godot supports multithreading, but not in the whole engine.
  8. Below is a list of ways multithreading can be used in different areas of Godot.
  9. Global scope
  10. ------------
  11. Most :ref:`Global Scope<class_@GlobalScope>` singletons are thread-safe by default.
  12. Accessing servers from threads is supported. However, for the
  13. :ref:`rendering <doc_thread_safe_apis_rendering>` and
  14. :ref:`physics <doc_thread_safe_apis_physics>` servers,
  15. thread-safe operation must be enabled in the project settings first.
  16. This makes singletons ideal for code that creates dozens of thousands of instances
  17. in servers and controls them from threads. Of course, it requires a bit more
  18. code, as this is used directly and not within the scene tree.
  19. Scene tree
  20. ----------
  21. Interacting with the active scene tree is **not** thread-safe. Make sure
  22. to use mutexes when sending data between threads. If you want to call
  23. functions or set properties from a thread, you may use
  24. :ref:`call_deferred <class_Object_method_call_deferred>` or :ref:`set_deferred <class_Object_method_set_deferred>`:
  25. .. tabs::
  26. .. code-tab:: gdscript
  27. # Unsafe:
  28. node.add_child(child_node)
  29. # Safe:
  30. node.add_child.call_deferred(child_node)
  31. .. code-tab:: csharp
  32. // Unsafe:
  33. node.AddChild(childNode);
  34. // Safe:
  35. node.CallDeferred(Node.MethodName.AddChild, childNode);
  36. However, creating scene chunks (nodes in tree arrangement) outside the active
  37. tree is fine. This way, parts of a scene can be built or instantiated
  38. in a thread, then added in the main thread:
  39. .. tabs::
  40. .. code-tab:: gdscript
  41. var enemy_scene = load("res://enemy_scene.scn")
  42. var enemy = enemy_scene.instantiate()
  43. enemy.add_child(weapon) # Set a weapon.
  44. world.add_child.call_deferred(enemy)
  45. .. code-tab:: csharp
  46. PackedScene enemyScene = GD.Load<PackedScene>("res://EnemyScene.scn");
  47. Node enemy = enemyScene.Instantiate<Node>();
  48. enemy.AddChild(weapon);
  49. world.CallDeferred(Node.MethodName.AddChild, enemy);
  50. Still, this is only really useful if you have **one** thread loading data.
  51. Attempting to load or create scene chunks from multiple threads may work,
  52. but you risk resources (which are only loaded once in Godot) being tweaked
  53. by the multiple threads, resulting in unexpected behaviors or crashes.
  54. Only use more than one thread to generate scene data if you *really* know what
  55. you are doing and you are sure that a single resource is not being used or
  56. set in multiple ones. Otherwise, you are safer just using the servers API
  57. (which is fully thread-safe) directly and not touching scene or resources.
  58. .. _doc_thread_safe_apis_rendering:
  59. Rendering
  60. ---------
  61. Instancing nodes that render anything in 2D or 3D (such as :ref:`class_Sprite2D`
  62. or :ref:`class_MeshInstance3D`) is *not* thread-safe by default. To run the
  63. rendering driver on a separate thread, set the
  64. :ref:`Rendering > Driver > Thread Model <class_ProjectSettings_property_rendering/driver/threads/thread_model>`
  65. project setting to **Separate**.
  66. Note that the **Separate** thread model has several known bugs, so it may not be usable
  67. in all scenarios.
  68. .. warning::
  69. You should avoid calling functions involving direct interaction with the GPU
  70. on other threads, such as creating new textures or modifying and retrieving
  71. image data. These operations can lead to performance stalls because they require
  72. synchronization with the :ref:`RenderingServer<class_RenderingServer>`,
  73. as data needs to be transmitted to or updated on the GPU.
  74. .. _doc_thread_safe_apis_physics:
  75. Physics
  76. -------
  77. Physics simulation is *not* thread-safe by default. To run the physics servers
  78. on separate threads (making them thread-safe), enable the following project settings:
  79. - **PhysicsServer2D:** :ref:`Physics > 2D > Run on Separate Thread <class_ProjectSettings_property_physics/2d/run_on_separate_thread>`.
  80. - **PhysicsServer3D:** :ref:`Physics > 3D > Run on Separate Thread <class_ProjectSettings_property_physics/3d/run_on_separate_thread>`.
  81. GDScript arrays and dictionaries
  82. --------------------------------
  83. In GDScript, reading and writing elements from multiple threads is OK, but anything
  84. that changes the container size (resizing, adding, or removing elements) requires
  85. locking a :ref:`mutex <doc_using_multiple_threads_mutexes>`.
  86. Resources
  87. ---------
  88. Modifying a unique resource from multiple threads is not supported. However,
  89. handling references on multiple threads *is* supported. Hence loading resources
  90. on a thread is as well - scenes, textures, meshes, etc - can be loaded and manipulated
  91. on a thread and then added to the active scene on the main thread. The limitation here
  92. is as described above: one must be careful not to load the same resource from
  93. multiple threads at once. Therefore, it's easiest to use **one** thread for loading
  94. and modifying resources, and then the main thread for adding them.