So they have multiple 'threads', but those threads work sequentially? Why do they even design like this in the first place? Doesn't have any benefits right?
“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.
Seems like the same rationale as cooperative multitasking modes for RTOSs on microcontrollers without memory protection - each "thread" might handle different I/O requirements (polling game controller button input, setting up the next frame on the GPU, filling the sound buffer, etc.), and as long as none of them crash, they can all get enough CPU time to be soft-realtime.
This is in fact how all threading worked before processors started coming with multiple cores. Windows 95 used "sequential threads". Eventually we got "hyper-threading" which was indeed threads running simultaneously, and then ubiquitous multicore computing.
In win95 there is preemption. The kernel can swap out threads on a timer interrupt to create the illusion despite no actual multiprocessing. You don't need real multicore to have that. But the programming model is the same as if you had it.
Elsewhere on this thread (uhh the other kind) it sounds like the threads here are not preemptible. So cooperative multitasking.
Did you mean to respond to me? In a sibling to my original comment it looks like theclaw cites a page that implies the scheduler handles the "yield process" and does preempt running threads. Windows 3.1 used cooperative multitasking which is why a single program could "lock up" the whole system.
The programming model is not quite the same. You can get away with some things if you know only one thread is running at a time. You have to mutex a lot less for one.
I disagree. You don't know where in your code the scheduler will interrupt you, it could be any time, so if you do unsafe things to shared structures you still need the mutex, it's just less likely that you will get rescheduled at precisely the right moment to hit it.
In other words data races will still potentially cause another thread to see a data structure in an intermediate state. It will just be a rare bug instead of a potentially more common one.
