Task-threading-model.md

@@ -15,7 +15,7 @@ Concurrency is primarily limited by each task's dependencies, and therefore it's
 
 Dependencies are in most cases simple progress-integers ("reconstruction of previous reference frame should be below X") that are checked against their reference. There is no `pthread_cond_wait()` in the code - instead, tasks with unmet dependencies are simply kept in the task-queue.
 
-Most tasks are implicit dependencies of others. For example, entropy-parsing of a tile's sbrow can only start when the previous tile's sbrow has finished. Some of these dependencies are not reflected in the code. Instead, the tile-sbrow-entropy-parsing task "owns" its own task and can put itself back in the queue (or continue) once the previous tile-sbrow has finished parsing. This mechanism to continue iterating without needing interaction with the task-queue (and thus without needing a lock) is one way to reduce overhead in this system, especially at high thread-counts.
+Most tasks are implicit dependencies of others. For example, entropy-parsing of a tile's sbrow can only start when the previous tile's sbrow has finished. Some of these dependencies are not reflected in the code as dependencies per-se. Instead, the tile-sbrow-entropy-parsing task "owns" its own task object and its scheduling and can put itself back in the queue (or continue) once the previous tile-sbrow has finished parsing. This mechanism to continue iterating without needing interaction with the task-queue (and thus without needing a lock) is one way to reduce overhead in this system, especially at high thread-counts.
 
 At the same time, tasks can schedule implicit-dependency follow-up tasks. For example, when a deblock postfilter at sbrow=0 starts, it itself will plan to do cdef and restoration of that same sbrow also. At the same time, it will schedule deblock at sbrow=1 into the taskqueue, because it knows this task wouldn't be able to start until its own task has started. This effectively keeps the number of unschedulable tasks in the task-queue low, which again improves efficiency at high thread counts.