diff options
author | Campbell Barton <ideasman42@gmail.com> | 2021-06-09 18:55:42 +0300 |
---|---|---|
committer | Campbell Barton <ideasman42@gmail.com> | 2021-06-09 19:22:45 +0300 |
commit | 25d8ce16b53d64a9921243e9b4f816f97659b4be (patch) | |
tree | cd9f2f435f88367fd717e2f87c49ef722382267a /source/blender/blenlib/BLI_task.h | |
parent | 59553d47c0075404790214b63e0edc55c48c5d90 (diff) |
Cleanup: spelling in comments
Diffstat (limited to 'source/blender/blenlib/BLI_task.h')
-rw-r--r-- | source/blender/blenlib/BLI_task.h | 12 |
1 files changed, 6 insertions, 6 deletions
diff --git a/source/blender/blenlib/BLI_task.h b/source/blender/blenlib/BLI_task.h index 59020c9eb1e..83ccfda7e38 100644 --- a/source/blender/blenlib/BLI_task.h +++ b/source/blender/blenlib/BLI_task.h @@ -70,20 +70,20 @@ typedef enum TaskPriority { /** * Task isolation helps avoid unexpected task scheduling decisions that can lead to bugs if wrong * assumptions were made. Typically that happens when doing "nested threading", i.e. one thread - * schedules a bunch of main-tasks and those spawn new subtasks. + * schedules a bunch of main-tasks and those spawn new sub-tasks. * - * What can happen is that when a main-task waits for its subtasks to complete on other threads, + * What can happen is that when a main-task waits for its sub-tasks to complete on other threads, * another main-task is scheduled within the already running main-task. Generally, this is good, * because it leads to better performance. However, sometimes code (often unintentionally) makes * the assumption that at most one main-task runs on a thread at a time. * * The bugs often show themselves in two ways: - * - Deadlock, when a main-task holds a mutex while waiting for its subtasks to complete. - * - Data corruption, when a main-task makes wrong assumptions about a threadlocal variable. + * - Deadlock, when a main-task holds a mutex while waiting for its sub-tasks to complete. + * - Data corruption, when a main-task makes wrong assumptions about a thread-local variable. * * Task isolation can avoid these bugs by making sure that a main-task does not start executing - * another main-task while waiting for its subtasks. More precisely, a function that runs in an - * isolated region is only allowed to run subtasks that were spawned in the same isolated region. + * another main-task while waiting for its sub-tasks. More precisely, a function that runs in an + * isolated region is only allowed to run sub-tasks that were spawned in the same isolated region. * * Unfortunately, incorrect use of task isolation can lead to deadlocks itself. This can happen * when threading primitives are used that separate spawning tasks from executing them. The problem |