On 31/03/2015 13:05, Dr. David Alan Gilbert wrote:
> * Paolo Bonzini (pbonz...@redhat.com) wrote:
>>
>>
>> On 30/03/2015 19:46, Dr. David Alan Gilbert wrote:
>>>>>>> +PostcopyState postcopy_state_get(MigrationIncomingState *mis)
>>>>>>> +{
>>>>>>> + return atomic_fetch_add(&mis->postcopy_state, 0);
>>>>>>> +}
>>>>>>> +
>>>>>>> +/* Set the state and return the old state */
>>>>>>> +PostcopyState postcopy_state_set(MigrationIncomingState *mis,
>>>>>>> + PostcopyState new_state)
>>>>>>> +{
>>>>>>> + return atomic_xchg(&mis->postcopy_state, new_state);
>>>>>>> +}
>>>>>
>>>>> Which are the (multiple) threads are calling these functions?
>>> The main thread receiving the migration and the postcopy ram_listen_thread
>>> receiving the RAM pages.
>>> It's not actually racy between multiple threads updating it,
>>> it's sequenced so that the main thread initialises it and then
>>> hands over to the listen thread that takes it over from that point.
>>
>> I would use atomic_mb_read/atomic_mb_set here.
>
> The benefit of the atomic_xchg is that I get the old value back so
> that I can sanity check I was in the state I thought I should have
> been.
Ok, you can still pair atomic_xchg with atomic_mb_read, it's a bit cheaper.
Paolo
