Re: Small confusing regarding __atomic_load_n()

[Jules Colding <colding at venalicium dot dk>]

On Sep 18, 2013, at 5:04 PM, Jonathan Wakely <jwakely.gcc@gmail.com> 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