Luo Yun of C ++

Luo Yun of C ++

Disclaimer: You shoshould first (but not the least) understand the fundamentals of multithreading memory models to be able to read the following text. I personally recommend you start with the related C ++ 0x Memory Model proposals if you're a C ++ programmer, or the Java memory model if you're a Java programmer. that being said, the principles behind the proof apply to all kinds of the so-called data-race-free models.

If it happens that you 've been slogging through all the glories proposals of C ++ 0x memory model, and found yourself tripped up by the proof in question. then you'll find this post useful. otherwise I suggest you at least read this paper before going on.

I do assume that you have a sufficient understanding of the fact that multithreading is becoming, if not has already become, the next big event and general skill in the programming field. there're flames all over the places. and since C ++ is one of my favorite programming languages, and, unfortunately one that has not supported ded a multithreading Memory Model of some sort (well, not until C ++ 0x is published), I kept tracking of all the progress that has been made with respect to it. it turns out that multithreading is this extremely tricky yet interesting business.

OK, enough said, let's get down to business. just one last thing though, I only write this post to explain the proof informally, so this is not going to be like an "Introduction to C ++ 0x Memory Model" Post (although I do have the plan to write one of those, just so long as there's enough time), instead, I'll go without any further preamble. for those of you who're not familiar with the upcoming, brand-new C ++ 0x memory model, and do consider yourself a C ++ Programmer (or, you know, A programmer in general), I strongly suggest you start now.

 

 

Anyway, the original paper is here. Let's take a look at its conclusion first:

 

If you stick to simple synchronization rules, that is, using only lock and unlock to avoid data-races, then a consistent execution of your program will exhibit behavior that you can reason about according to one of its corresponding sequentially consistent executions.

 

Well, put simply, this states that you can regard your program as being executed by sequentially interleaving the actions of all the threads, provided that you use only lock and unlock to avoid data-races.

 

To state it even more loosely, it actually means that data-race-free implies sequential consistency, the most intuitive consistency model.

 

Actually, this is one of the most fundamentally important conclusions with respect to this mainstream multithreading memory model. it has two very nice implications. first, it says that we only need to make our program data-race-free to get sequential consistency; and second, it gives the implementations (compilers, VMS, and hardwares) great latitude in optimizing the code, most of them being instruction reorderings of course.

 

For example, let's consider the code snippet below:

 

Int X, Y; // globals

Thread 1 thread 2

Y = 1; X = 1;

R1 = x; r2 = y;

 

If the code is executed sequential-consistently, R1 and R2 coshould never be both 0, because if we observed that R1 is 0, then it must be the case that "R1 = x" precedes "x = 1 ", together with the other two relations ("y = 1" precedes "R1 = x" and "x = 1" precedes "R2 = Y "), we can conclude that "y = 1" precedes "R2 = Y" (since the relation precedes is transitive under the sequential consistency interpretation), making R2 observe the value 1. and the same reasoning applies the other way around.

 

Unfortunately, however, sequential consistency is too strict in that it prevents invalid useful optimizations, such as instruction reordering. it's usually the case that, in a multithreaded program, the parts shared by two or more threads are rare. while present CPUs don't actually know the existence of threads, to achieve sequential consistency we 'd have to compile/execute the whole program sequential-consistently, not just the inter-thread parts. so relying on hardware obviusly is not an option. this leaves us with the only choice of manually specifying which parts of a program are inter-threaded. and that's where all those synchronization instructions kick in.

 

Like in the above example, Most of today's compiler cocould reorder the two actions in each thread, thus making "R1 = R2 = 0" a perfectly legitimate outcome, and even if your compiler hadn't done it, your CPU will do it, too. but if we sprinkle some special crumbles (I. e. synchronization primitives) over our code, we'll get sequential consistency easily without forcing the whole implementation to obey sequential consistency rules:

 

Int X, Y;

Mutex MX, my;

Thread 1 thread 2

Lock (my); lock (MX );

Y = 1; X = 1;

Unlock (my); unlock (MX );

Lock (MX); lock (my );

R1 = x; r2 = y;

Unlock (MX); unlock (my );

 

Here, we simply used lock/unlock primitives to avoid data-race which cocould cause the infamous undefined behavior. since lock/unlock primitives enforce happens-before relations, and more importantly, act as one-way memory fences, this will get us sequential consistency, in addition to data-race-free-ness. I think the reasoning shoshould be pure simple, so I'll just leave it to you.

 

So what's the big deal? I mean, didn't people always do that? The big deal is, we use lock/unlock to avoid all the data-races, but as a result, we not only get to avoid the data-race, we also get the whole sequential consistency property. that's a really nice guarantee. it means that we don't have to worry about all the gory optimizations that might change the behavior of our code; we just have to make our code data-race-free, and the whole sequential consistency property just comes as a side-effect. and maybe more importantly, the implementations still get to keep their unawareness of threads, hence most of the optimizations still go underneath, but you just don't have to worry about them anymore.

 

The principle of data-race-free memory model is basically that the compilers or CPUs know nothing about threads; they compile code or execute instructions as if there were just one thread, doing all those crazy optimizations that are only legitimate in a single-thread context; the programmers, however, put some specially instructions in their code to prevent the crazy Optimizations in some areas, which, supposedly, are those places where multiple threads communicate with each other. this way not only do we get to preserve the correctness (sequential consistency) of our code, but we get to allow most of the useful optimizations. this proved to be the most practical trade-off before the super-intelligent compiler or CPU shows up which cocould efficiently recognize all those inter-thread communication code for us, and respect them while doing all the optimizations.

 

Anyway, I'll just get down to the proof "data-race-free implies SC" before you get all bored

 

Let's consider a consistent execution of a program on a given input. recall that, informally, "consistent" means this special execution respects all the happens-before relations that are specified in the Code using lock and unlock primitives, although it might not respect the is-sequenced-before relations, which is pretty much what instruction reordering is all about.

 

So, let's call this particle execution P', and apparently it's not exactly sequentially consistent, because presumably there 'd be lots of instructions that cocould and wocould be reordered. however, what's important to us is if it exhibits the exact behavior of one of its corresponding sequential consistent counterparts. for convenience, let's just call one of the latter ones p.

 

But what is this p anyway? How do we get it? Remember that we said a consistent execution showould respect all the happens-before relations in the original program? So all the happens-before relations in P' must be preserved in P, which doesn' t contradict the sequential consistency of P. and plus, P will have all those is-sequenced-before relations, which will make all the actions from each thread appear in the order in which they appear in their own thread. but it's still not enough; To make p a sequentially consistent execution, all the actions shoshould appea R in a total order. recall that two actions from different thread that aren't ordered by happens-before cocould be executed in any order, so why don't we just arbitrarily order them? This way we get to keep each thread order and will get a total order.

 

Now, we're going to prove that we cocould use P to reason about the exact behavior of p', which simply means that, despite all the optimizations that have been made to our code, we cocould still regard it as being executed sequential-consistently.

 

Apparently, from the standpoint of main memories, there're just two kinds of actions stored med by a CPU-store and load. so, an execution of a program can be seen as consisting of only stores and loads. when we're re reasoning about the behavior of a program on a given input, we are actually predicting the value seen by each load.

 

So let's just consider a load L in P', and assume the value seen by it is generated by a store svisible. to prove that we cocould use P to reason about the behavior of p', we just have to show that svisible is the last preceding store in P that stores to the same location.

 

Clearly, if svisible and l are in the same thread in P', svisible must be sequenced before l, because if not, it wocould either implies a violation of C ++ 03; 5p4 (which basically says that there shall not be conflicting accesses of the same scalar between two adjacent sequence points) or conflicts the intra-thread semantic constraints (which basically says that it shoshould at least appear to be the case that a participant thread is executed sequentially, lew.each load see the value written by the preceding store ).

 

However, what if svisible and l reside in different threads? Then svisible must happen-before l because of the No data-race rule.

 

So, it turned out that svisible either is-sequenced-before l or happens-before l. and here comes the real brilliant part. we 've already known that P' respects all the happens-before relations in the original program, so if svisible happens-before l in P ', then it must happen-before l in P. but what if svisible is-sequenced-before l? Recall that P is sequentially consistent; it respects all the is-sequenced-before relations in the original program. so if svisible is-sequenced-before l, then it must be the case that it's still sequenced before l in P. hence, in either case, svisible is before l in P. so, to get to the final conclusion that says we can use P to reason about the behavior of p ', it's left to be shown that there're no other stores to the same location that come sandwiched between svisible and L in P, because this way when we decide in P that l sees the value written by svisible, it wocould actually be the case that l wocould see the value written by svisible in P', too, which is what "reasoning about the behavior of P 'using P" is all about.

 

Let's use the powerful "ctictio ad absurdum ". let's assume that there's another smiddle sitting between svisible and L in P. since P clearly is data-race-free (P and P' both are consistent executions of the original data-race-free program), smiddle, svisible, and l must be fully ordered (by is-sequenced-before or happens-before ). however, svisible and l are already ordered. so the only possibilities left are:

 

Smiddle is-sequenced-before/happens-before svisible

 

L is-sequenced-before/happens-before smiddle

 

Svisible is-sequenced-before/happens-before smiddle is-sequenced-before/happens-before l

 

The reason the first two aren't possible is that it contradicts the reverse ordering in p. here's the logic: If smiddle is-sequenced-before/happens-before svisible, then it will come before svisible in P, too (because is-sequenced-before and happens-before are the two kinds of relations that P must respect), thus contradicting our assumption that smiddle sits between svisible and L. the same reasoning applies to the second case.

 

To show that the last case isn' t possible either, we just have to recall that P' is a consistent execution (which means every load sees the last preceding store to the same location ), so if smiddle really comes between svisible and L in P (in the sense shown by the last case below) and since P 'have to respect the happens-before relations (and the is-sequenced-before relation in this case), smiddle Will comes between them in P', too, thus blocking the line of sight from L to svisible, making l see the value written by smiddle, not svisible, which will, in turn, make P' an inconsistent execution.

 

So it turns out this imaginary smiddle appears neither here nor there. Then it must not exist, concluding the proof.