Re: synchronize with a non-atomic flag

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Sun, Oct 08, 2017 at 05:12:18PM +0800, Yubin Ruan wrote:
> 2017-10-06 13:52 GMT+08:00 Yubin Ruan <ablacktshirt@gmail.com>:
> > Hi,
> > I saw lots of discussions on the web about possible race when doing
> > synchronization between multiple threads/processes with lock or atomic
> > operations[1][2]. From my point of view most them are over-worrying.
> > But I want to point out some particular issue here to see whether
> > anyone have anything to say.
> >
> > Imagine two processes communicate using only a uint32_t variable in
> > shared memory, like this:
> >
> >     // uint32_t variable in shared memory
> >     uint32_t flag = 0;
> >
> >     //process 1
> >     while(1) {
> >         if(READ_ONCE(flag) == 0) {
> >             do_something();
> >             WRITE_ONCE(flag, 1); // let another process to run
> >         } else {
> >             continue;
> >         }
> >     }
> >
> >     //process 2
> >     while(1) {
> >         if(READ_ONCE(flag) == 1) {
> >             printf("process 2 running...\n");
> >             WRITE_ONCE(flag, 0); // let another process to run
> >         } else {
> >             continue;
> >         }
> >     }
> >
> > On X86 or X64, I expect this code to run correctly, that is, I will
> > got the two `printf' to printf one after one. That is because:
> >
> >     1) on X86/X64, load/store on 32-bits variable are atomic
> 
> Ah...this assumption is wrong at the first place. Atomic access on
> 4-bytes integers is guaranteed only when these integer is aligned on a
> 4-bytes memory address boundary...

Indeed, accesses crossing cachelines normally won't guarantee you
much of anything other than painful debugging sessions.  ;-)

						Thanx, Paul

> Yubin
> 
> >     2) I use READ_ONCE/WRITE_ONCE to prevent possibly harmful compiler
> > optimization on `flag'.
> >     3) I use only one variable to communicate between two processes,
> > so there is no need for any kind of barrier.
> >
> > Does anyone have any objection at that?
> >
> > I know using a lock or atomic operation will save me a lot of
> > argument, but I think those things are unnecessary at this
> > circumstance, and it matter where performance matter, so I am picky
> > here...
> >
> > Yubin
> >
> > [1]: https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong
> > [2]: https://www.usenix.org/conference/osdi10/ad-hoc-synchronization-considered-harmful
>