Okay. So let's continue our exploration of multiprocessor systems or small
multiprocessor systems. And we left off talking about concurrency
and one of the things we talked about the end of class or, or just a recap actually
before we go there that let's, let's talk about Sequential Consistency again as a
model. So Sequential Consistency as a model
basically says that you have lots of different threads executing.
And the ordering of the memory references from the different threads to be inner
leave but everyone has to agree on what ordering is.
And all the threads have to agree and see the same ordering and the ordering of the
loads in the stores in the respective memory references have to be some valid
ordering from the thread. So you can't reorder within the thread.
So if you have two threads and you have let's say try four fingers here and each
of your hand are for familiar references you can have some inter leaving.
You can have some other inter leaving. You can have that inter leaving.
You can have all these possible combinations leaving so what's not valid
is to have my two fingers sort of change order there and that is that's
sequentially consistent. Having said that, we talked about building processors
up to this point which are not do not maintain that order, so we talked about
out of order processors and out of order memory systems, which by definition are
not doing this sequentially consistent notion here.
And if you want performance, as we talked about, sometimes you want to move loads
around, you want to push the load up so you can get the, the operation out to the
memory system early. You try to push the store down because,
you haven't computed the result yet, and you want to be able to, sort of, compute
the result before you go push it out to the memory system.
So these things fight against each other. Having a strict memory model, something
like sequential consistency, and having good performance.
And in fact, you're probably not going to find any
processor which actually implements, true sequential consistency.
or. I'm trying to think.
Maybe the, one of the, I, I, I, I don't want to say no because I'm, I, I have a
hunch that the original, one of the original shared memory processes, the RP3
by IBM I believe might have had a very strict memory model.
But, besides that I don't think it had caches.
most, most things do not come even close to this.
But we talk about sequencially consistent, or sequencial consistency as
a good model, because a programmer likes to think about this.
They like to think that when they write a piece of code what they execute happens
in order, and it happens in order relative to every other piece of code
happening on, on other threads. So, just to recap, what this ends up
happening, what this ends up doing is, sequencial consistency, we, we had talked
about having sort of ordering between loads in stores on the same processor
before, and you might, you can break that maybe if they're two different addresses.
But Sequential Consistency adds additional arcs in our dependency graph
where every memory instruction in one thread is dependence on all the previous
memory instructions. That's one way to reason about not
reordering anything so if you introduce all those arcs you are not going to
accidentally break Sequential Consistency.
But sequential consistency says nothing about dependence from one thread to
another thread so there is no arc crossing between these two threads.
So hence you have all valid inter leaving there.