Jeff Squyres, le Fri 12 Mar 2010 08:05:04 -0800, a écrit :
> On Mar 12, 2010, at 7:51 AM, Samuel Thibault wrote:
> > > To support that, do we need to make internal variables and fields be volatile?
> >
> > ?! I fail to see why we would need that.
> > If some threads uses a function that modifies a topology object, no
> > other thread should be reading it of course, since the reader will
> > possibly read incoherent data. A volatile qualifier can not fix that,
> > only mutexes (or transactional memory :) ) can.
>
> Right -- that's not what I'm asking about.
>
> Even in this scenario:
>
> 1. thread A calls hwloc_topology_init(&a)
> 2. thread A calls hwloc_topology_load(a)
> 3. thread A launches thread B
> 4. thread B calls hwloc_topology_get_*(a...)
> 5. threads A and B synchronize
> 6. thread A calls hwloc_topology_load(a)
> 7. thread B calls hwloc_topology_get_*(a...)
>
> If the topology struct is not marked volatile (or the fields or whatever), then the compiler *might* assume that all the data in cache/registers from step 4 may still be valid in step 7.
This is like with any libc structure that you pass between threads. If
step 5 (synchronization) does not perform a compiler and hardware
barrier, you may have incoherencies, yes.
> volatile effectively forces cache misses so that step 7 will guarantee to read from memory again,
That is not the proper way to deal with it. A full memory barrier at
step 5 is just enough and much more efficient.
> > > If we say that applications need to provide their own synchronization
> > > between readers and writers, atomic writes shouldn't be an issue,
> > > right?
> >
> > I do not understand this either.
>
> Since writes back to memory may be delayed, it could be possible that a write of a value in a topology struct only gets partially written before a read for that same value comes in from another thread (even if the threads *think* they have synchronized, such as above).
Ok, same answer: use a memory barrier in the application (semaphores,
mutexes and spinlocks already do that for you actually).
> If we say that applications need to provide their own synchronization
> between readers and writers, atomic writes **could still** be an issue,
> right?
With a full memory barrier, you do not have any issue.
Samuel
|
![[Flag]](../../../../../community/mirrors/flag-us.gif){kind=small}