[Autogenerated] The last topic I'd like to briefly discuss in
this module is high arc core synchronization.
All the synchronization we've seen so far with threads work at,
at a zero or one.
And That's because the scheduler is alive,
and can wake up on these processors, to make scheduling changes.
It's possible.
To do weights, for example.
However, when we have interrupts or D PCs running the AR code is two or higher,
what happens if a D PC routine needs to access some shared data
that is shared with another D PC or the interrupt,
service routine for that same driver.
How can they protect against concurrent access using a mute,
is not going to work out its going to blue screen the system
because mute or fast tex imply weight but waiting.
Is not possible when the our co is two or higher.
So, these objects, are completely useless.
In the This regard all the other objects we talked about as well such as Sema,
forms and events, they are completely useless at arr,
query two or higher still,
we might need to prevent data races in such cases because you
might have multiple processors running code that accesses the
same data So we need to do something, in order for this to work,
and the solution.
To that is an object which functions very similarly.
To a tex conceptually called the spin lock.
The idea here, is that only one processor at a time can acquire that spin lock,
and make forward progress, all the other processors.
That try to get access to that same spin lock will busy wait.
They will not get into a normal weight state where the CP can do other stuff.
It's not possible.
The scheduler can't wake up on those processors.
They will busy wait,
continually pulling that spin lock until it becomes available.
That's what we can do in this kind of case.
So sometimes pin, os are needed.
And this is a bit beyond the scope of this course.
But these are some pointers here who might want to look up this information,
more in the documentation or online.