Hi,
rdos wrote:
Turns out the logic doesn't work after all, and the reason is that the task can be scheduled on a new core before the old core loads a new thread.
It turns out that having massive concurrency/race condition bugs doesn't work after all (but the FPU/MMX/SSE/AVX state loading is fine if/when done correctly)?
halofreak1990 wrote:
Since loading/saving FPU state is likely part of the scheduling logic, wouldn't it be simpler to simply make (part of) the actual scheduling uninterruptible?
Typically there's "something" to make sure that the same thread isn't being executed by different CPUs at the same time. For an example, maybe you've got a queue of "ready to run" threads, where the scheduler has code to atomically add/remove threads onto/from the "ready to run" queue; and where if a thread is running (on any CPU) it's not on the "ready to run" queue and therefore no other CPUs can switch to that thread. Of course there's many other ways of doing it - the point is that there must be "something" to ensure that other CPUs won't switch to an already running thread.
Now; given that there must be "something" to ensure that other CPUs won't switch to an already running thread, that "something" can be used to ensure that no other CPU can switch to a thread until after all its state has been saved correctly (including its FPU/MMX/SSE/AVX state). Essentially, a thread is considered "running" until all of its state has been saved (and not just until part of its state has been saved).
Cheers,
Brendan