-With these declarations, we didn't yet tell ORWL much about the resources to
-which these handles refer, nor the type (read or write) or the priority (FIFO
-position) of the access. This is done in code
-\Lst{algo:ch6p3ORWLinit}. The handles for
-\Lst{algo:ch6p3ORWLtrans} are given first, \texttt{GPUhandle} will be
-accessed exclusively (therefore the \texttt{write}) and, as said,
-\texttt{curRead} is used shared (so a \texttt{read}). Both are inserted in the
-FIFO of there respective resources with highest priority, specified by the
-\texttt{0}s in the third function parameter. The resources to which they
-correspond are specified through calls to the macro \texttt{ORWL\_LOCATION},
-indicating the task (\texttt{orwl\_mytid} is the ID of the current task) and the
-specific resource of that task, here \texttt{GPU} and \texttt{curBlock}.
-
-Likewise, a second block of insertions concerns the handles for
-\Lst{algo:ch6p3ORWLrcopy}: \texttt{newWrite} reclaims an exclusive
-access and \texttt{remRead} a shared. \texttt{remRead} corresponds to a
-resource of another task; \texttt{previous(orwl\_mytid)} is supposed to return
-the ID of the previous task in the cycle. Both accesses can be effected
-concurrently with the previous operation, so we insert with the same priority
-\texttt{0} as before.
-
-Then, for the specification of the third operation
-(\Lst{algo:ch6p3ORWLlcopy}) we need to use a different priority: the
-copy operation from \texttt{nextBlock} to \texttt{curBlock} has to be performed
-after the other operations have terminated.
-
-As a final step, we then tell ORWL that the specification of all accesses is
+With these declarations, we didn't yet tell ORWL much about the resources to
+which these handles refer, nor the type (read or write) or the priority (FIFO
+position) of the access. This is done in code \Lst{algo:ch6p3ORWLinit} that
+shows six insertions of handles into their respective FIFO locations. The
+handles \texttt{GPUhandle} and \texttt{curRead} are given first (lines 3 and 4),
+\texttt{GPUhandle} will be accessed exclusively (therefore the \texttt{write})
+and, as said, \texttt{curRead} is used in shared access (so a
+\texttt{read}). Both are inserted in the FIFO of their respective resources with
+highest priority, specified by the \texttt{0}s in the third function
+parameter. The resources to which they correspond are specified through calls to
+the macro \texttt{ORWL\_LOCATION}, indicating the task (\texttt{orwl\_mytid} is
+the ID of the current task) and the specific resource of that task, here
+\texttt{GPU} and \texttt{curBlock}.
+
+Likewise, a second block of insertions concerns the handles \texttt{remRead} and
+\texttt{nextWrite} (lines 8 and 9). \texttt{nextWrite} reclaims an exclusive
+access and \texttt{remRead} a shared one. \texttt{remRead} corresponds to a
+resource of another task; the call to \texttt{previous(orwl\_mytid)} is supposed
+to return the ID of the previous task in the cycle. Both accesses can be
+performed concurrently with the previous operation, so we insert them with the
+same priority \texttt{0} as previously.
+
+Then, for the specification of the third operation related to handles
+\texttt{nextRead} and \texttt{curWrite} (lines 13 and 14), we need to
+use a different priority: the copy operation from data locations \texttt{nextBlock} to
+\texttt{curBlock} has to be performed after the other operations have
+terminated (so the priority \texttt{1}).
+
+As a final step, we then tell ORWL (line 16) that the specification of all accesses is
