[dmd-concurrency] draft 7

[Michel Fortin]

Le 2010-02-01 à 17:52, Fawzi Mohamed a écrit :

> On 1-feb-10, at 23:43, Michel Fortin wrote:
> 
>> Le 2010-02-01 à 17:26, Fawzi Mohamed a écrit :
>> 
>>> you don't need a barrier, you need a volatile statement to avoid compiler optimizations
>> 
>> Is that something the compiler could do in an optimization pass, I mean determining when a barrier isn't necessary and volatile is enough? For instance when periodically checking a shared variable in a loop?
> 
> I think that there is some confusion about what barriers do, they just introduces a partial ordering In general a compiler cannot decide automatically to remove them.

But the compiler could choose not to add them when they would have no effect. That's what I meant by optimization.

Of course if you're putting barriers yourself the compiler shouldn't optimize them away.

> The handshake Andrei was talking about really isn't the point here.
> The thing is that the compiler should avoid some optimizations, in the sense that it should always load from memory (and not store it in a register and read it from there).
> A barrier alone has nothing to do with that, but a read barrier can ensure that what is visible after the read is for sure the status after a corresponding write barrier.

I was assuming that all accesses to a shared variable would be volatile in addition to having a barrier.

Also, if I understand well, with shared variables it's not the programmer who put barriers but the compiler. The compiler could be conservative and put barriers everywhere, or it could be smarter and put them only where required for sequential consistency among access to shared variables (which I called optimization).

So for instance, this:

	shared int flag;

	int wait() {
		int loopCount;
		while (flag == 0) {
			++loopCount;
		}
		return loopCount;
	}

doesn't warrant a barrier at each loop iteration, one barrier before the loop should be sufficient (even though all accesses should be volatile).

That's if I understand barriers correctly. It's not a subject I master very well.

What's important is that the compiler preserves sequential consistency and atomicity of reads/writes for shared variables. Whether it's by inserting barriers everywhere or doing so just where it's really needed is only a quality of implementation issue.

Perhaps the compiler should be allowed to reorder access to non-shared variables across the barriers it inserts for shared variables. Since those variables are not shared, it shouldn't have any effect, right?

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/