Task-threading-model.md

@@ -4,7 +4,7 @@ Dav1d can execute the following task types:
 - entropy-parse one tile-sbrow of entropy data;
 - reconstruct (prediction+inverse transform) one tile-sbrow of frame data;
 - deblock (in either direction) or cdef for one sbrow of frame data;
-- loop restoration for one slice (~64 pixels high) of frame data;
+- loop restoration for one sbrow of frame data;
 - film grain synthesis for one slice (32 pixels high) of frame data.
 
 Dav1d has some additional task types to administratively blend these tasks together across multiple frames at the same time, and can therefore effectively process multiple tiles, sbrows and frames at the same time.
@@ -13,7 +13,7 @@ Dav1d has some additional task types to administratively blend these tasks toget
 
 Concurrency is primarily limited by each task's dependencies, and therefore it's critically important that these are minimal-but-complete and that the scheduler orders tasks to achieve maximal parallelism.
 
-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.
+Dependencies are in most cases simple progress-integers that are checked against their reference ("reconstruction of previous reference frame should be above X"). 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 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.