On Wed, 31 Jan 2007, Benjamin Herrenschmidt wrote:
- We would now have some measure of task_struct concurrency. Read that twice,
it's scary. As two fibrils execute and block in turn they'll each be
referencing current->. It means that we need to audit task_struct to make sure
that paths can handle racing as its scheduled away. The current implementation
*does not* let preemption trigger a fibril switch. So one only has to worry
about racing with voluntary scheduling of the fibril paths. This can mean
moving some task_struct members under an accessor that hides them in a struct
in task_struct so they're switched along with the fibril. I think this is a
manageable burden.
That's the one scaring me in fact ... Maybe it will end up being an easy
one but I don't feel too comfortable...
We actually have almost zero "interesting" data in the task-struct.
All the real meat of a task has long since been split up into structures that can be shared for threading anyway (ie signal/files/mm/etc).
Which is why I'm personally very comfy with just re-using task_struct as-is.
NOTE! This is with the understanding that we *never* do any preemption. The whole point of the microthreading as far as I'm concerned is exactly that it is cooperative. It's not preemptive, and it's emphatically *not* concurrent (ie you'd never have two fibrils running at the same time on separate CPU's).