On Sep 18, 2013, at 5:04 PM, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: > On 18 September 2013 15:54, Jules Colding wrote: >> Hi, >> >> When I do something like: >> >> thread 1: >> >> int count = 0; >> int *thread_var = &count; >> >> thread 2: >> >> __atomic_store_n(thread_var, 7, __ATOMIC_RELEASE); >> >> >> Do I then need to do the following in thread 3? > > What are you trying to do? Please see below. >> thread 3 option 1: >> >> *thread_var = __atomic_load_n(thread_var, __ATOMIC_ACQUIRE); > > This reads the value of *thread_var, returns it, then (non-atomically) > stores it back in *thread_var. What's the point of that? If you need > the value, you still haven't read it back from *thread_var (and you > may have created a race condition by writing to *thread_var.) Actually, in my case this could make sense. See below. > Or do this suffice? >> >> thread 3 option 2: >> >> __atomic_load_n(thread_var, __ATOMIC_ACQUIRE); > > This loads the value then discards it again. > > I think you want: > > int var = __atomic_load_n(thread_var, __ATOMIC_ACQUIRE); Not really. What I have is a variable which is shared by two threads, but for the most part only read and written in one of them. One thread runs continually in a loop, the other does not. Then, occasionally, I'm pausing the looping thread. From the other thread I then want to read *thread_val and set it to another value. Then I restart the looping thread which should now have the be able to see the new value of *thread_val. I was merely concerned that the new value of *thread_val was returned from __atomic_load_n() but not yet necessarily accessible by simply dereferencing thread_val. Anyways, you've cleared up my concerns, thanks. -- jules
