On Fri, Jul 29, 2016 at 10:54:21AM -0600, Jeff Law wrote:
> On 07/29/2016 10:03 AM, Jeff Law wrote:
> > > > It's been a couple years since I've really thought about these kinds of
> > > > synchronization issues -- is it really safe in a weakly ordered
> > > > processor to
> > > > rely on the mutex lock/unlock of the "object_mutex" to order the
> > > > loads/stores of "unseen_objects" and "seen_objects"?
> > > >
> > > I am pretty sure it is. After mutex unlock another cpu will not see
> > > old value (provided it uses acquire semantics to read value).
> Just a followup because this has been bugging me...
>
> Release/acquire provides synchronization between threads releasing and
> acquiring the same atomic variable. A mutex, implemented using
> acquire/release semantics would provide a memory ordering of accesses to
> the mutex variable which is used to negotiate entry/exits to critical
> sections.
>
> I don't see how using a mutex on "object_mutex" gives us an ordering on
> "seen_objects" and "unseen objects" -- unless the mutex under the hood does
> a full memory barrier/fence, which AFAIU is not required.
>
But mutex has to make sure that no write will leave critical section,
not only writes to mutex variable itself.
> This is a bit moot since we're likely going to go with Jakub's patch...
>
Still interesting topic to understand. Jakub's patch checks only one
variable in common case, so in that regards it's even better for my use
case.
--
Gleb.
