On 10/18/05, Zsejki Sorin Miklós <[EMAIL PROTECTED]> wrote: > Rodrigo Kumpera wrote: > > >On 10/18/05, Archie Cobbs <[EMAIL PROTECTED]> wrote: > > > > > >>Rodrigo Kumpera wrote: > >> > >> > >>>This won´t help to find the spots that require memory barriers, as > >>>these are only an issue on SMP systems. But your idea should not be > >>>discarded as it may help with other kinds of problems. > >>> > >>> > >>Good point.. interesting question how you could check that too.. > >>perhaps for multi-CPU systems you'd want to insert random length > >>delay loops (instead of context switches) or something. A context > >>swith would probably result in indirect flushing of the CPU state > >>anwyay, effectively the same as a barrier between every instruction. > >> > >>-Archie > >> > >>__________________________________________________________________________ > >>Archie Cobbs * CTO, Awarix * http://www.awarix.com > >> > >> > >> > >> > > > > > >Well, I think this kind of test requires that the thread observing > >mutation be busy-waiting for changes and the test must be repeated a > >huge ammout of times. For example, the new JMM says that changes to > >volatile variables must be visible in the same order as they happen, > >so: > > > >volatile int a = 0, b = 0; > > > >//Thread 1 repeats the following: > >a = 0; > >b = 0; > >a = 1; > >b = 2; > > > >//Thread 2 must never see b = 2 and a = 0, so it repeats the following: > > > > > Why not? After the a = 0; in the first thread, this is the case, isn't it? > > >int ra = a; > >int rb = b; > >if(a == 0 && b == 2) //signal error > > > >Given it's a SMP machine, both threads will be running concurrently. > > > > > > >
You're right, the following test would test the proper behavior My fault, the proper way to test this is the following: //Thread 1 a = 0; b = 0; int i = 0; //repeat this until positive overflow ++i; a = i; b = i; //Thread 2 keep testing this until positive overflow: int ra = a; int rb = b; if(rb > ra ) //signal error, change to 'b' observed before change to 'a'
