“The RSP executes both graphics and audio processes. A graphics process sometimes extends over one frame, but an audio process must be provided in each frame to prevent inappropriate pausing. Therefore, in each frame, if the graphics task is executing, the Scheduler suspends it and saves the task state. Then it starts the audio task executing and prepares the RSP for the restart of the graphics task execution when the audio task finishes.”
I think the thread here, really means it is a conceptually independent 'processing unit' on its own, which reads the global state of some sort, then make the modification to it. They have multiple such 'threads', each corresponding to some particular task, but with no explicit locks.
Now it makes more sense to me. Threads here are more logical isolation of functionalities, not really parallel execution workers.
I was automatically associating threading with parallelism, but this makes sense for 'concurrency' even if there is only one of them are working at the time.
“The RSP executes both graphics and audio processes. A graphics process sometimes extends over one frame, but an audio process must be provided in each frame to prevent inappropriate pausing. Therefore, in each frame, if the graphics task is executing, the Scheduler suspends it and saves the task state. Then it starts the audio task executing and prepares the RSP for the restart of the graphics task execution when the audio task finishes.”
[1] http://n64.icequake.net/doc/n64intro/kantan/step2/1-7.html