On Mar 12, 2010, at 8:45 AM, Samuel Thibault wrote:
> > The discussion we've had sounds like it's somewhat equivalent to
> > MPI_THREAD_SERIALIZED -- you can do whatever you want as long as you ensure
> > a) there's only writer 1 thread to a given object at a time, and b) the app
> > is respons
Jeff Squyres, le Fri 12 Mar 2010 08:38:48 -0800, a écrit :
> On Mar 12, 2010, at 8:31 AM, Samuel Thibault wrote:
> > No, because that will not automatically issue hardware memory barriers,
> > which are needed on basically all architectures but x86 (which has
> > in-order stores) to ensure seeing w
On Mar 12, 2010, at 8:31 AM, Samuel Thibault wrote:
> No, because that will not automatically issue hardware memory barriers,
> which are needed on basically all architectures but x86 (which has
> in-order stores) to ensure seeing writes coherently.
Ok, fine.
I'm not understanding how this conve
Jeff Squyres, le Fri 12 Mar 2010 08:25:11 -0800, a écrit :
> On Mar 12, 2010, at 8:16 AM, Samuel Thibault wrote:
>
> > With a full memory barrier, you do not have any issue.
>
> So we're saying that the only way to use hwloc safely with multiple different
> thread readers and writers is to do a
On Mar 12, 2010, at 8:16 AM, Samuel Thibault wrote:
> With a full memory barrier, you do not have any issue.
So we're saying that the only way to use hwloc safely with multiple different
thread readers and writers is to do a full memory barrier across the entire
machine? That seems like a big
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 mod
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 cou
Jeff Squyres, le Fri 12 Mar 2010 07:35:44 -0800, a écrit :
> On Mar 11, 2010, at 10:12 PM, Brice Goglin wrote:
> > I guess we a thread-safety section in hwloc.doxy to document that all
> > topology modifiers (most of hwloc_topology_* functions, not all of them)
> > cannot run concurrently.
>
> To
On Mar 11, 2010, at 10:12 PM, Brice Goglin wrote:
> I guess we a thread-safety section in hwloc.doxy to document that all
> topology modifiers (most of hwloc_topology_* functions, not all of them)
> cannot run concurrently.
To support that, do we need to make internal variables and fields be vola
On Mar 12, 2010, at 12:01 AM, Samuel Thibault wrote:
> That being said, we could easily add a mutex which we take in write
> operations to become completely THREAD_MULTIPLE-safe, as there aren't so
> many write operations.
For now, let's just leave the mutex out and solve the issue through
docum
Hello,
Jeff Squyres, le Thu 11 Mar 2010 17:34:59 -0800, a écrit :
> On Mar 11, 2010, at 3:57 PM, Samuel Thibault wrote:
>
> > > What *is* hwloc's policy about thread safety, anyway?
> >
> > It would be odd to not be threadsafe, considering the target
> > applications :) and I believe hwloc is al
Jeff Squyres wrote:
> 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. thread A calls hwloc_topology_load(a)
>
> On the one hand, you could say that an app would be dumb to do thi
On Mar 11, 2010, at 3:57 PM, Samuel Thibault wrote:
> > What *is* hwloc's policy about thread safety, anyway?
>
> It would be odd to not be threadsafe, considering the target
> applications :) and I believe hwloc is already.
Hmm. I'm not so sure. Consider:
1. thread A calls hwloc_topology_ini
13 matches
Mail list logo
