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 sequent ial consistency. or. I'm trying to think.
Maybe the, one of the, I, I, I, I don't wanna 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