[m-rev.] for review: [PATCH 1/4] Add thread_safe attribute to store procedures.

[Paul Bone]

On Wed, Jul 23, 2014 at 01:16:54PM +1000, Julien Fischer wrote:
> On Wed, Jul 23, 2014 at 8:37 AM, Paul Bone <paul at bone.id.au> wrote:
> 
> > On Wed, Jul 23, 2014 at 01:22:50AM +1000, Julien Fischer wrote:
> > >
> > > On Tue, 22 Jul 2014, Peter Wang wrote:
> > >
> > >> The mutvar procedures are not truly thread-safe but neither does
> > >> obtaining a global lock make them become thread-safe in a useful way,
> > >> except perhaps avoiding data races.  On the other hand, the global lock
> > >> inhibits parallelism in programs that do use mutvars in a thread-safe
> > >> manner.
> > >
> > > The only ones that are not thread safe are those that are attached to
> > > the I/O state since that is the only store state that can be split by a
> > > call to spawn.  IMO, arranging for thread safe access to I/O mutvars is
> > > the programmer's reponsibility -- as Paul said, there should be a a
> > > prominent note about this in the documentation.  This is fine by me
> > > otherwise.
> >
> > You're right. since stores use di/uo modes this is a moot point.
> 
> 
> No, it's a valid concern for I/O mutvars, just not the others.

I thought I was trying to agree with you.  I'm now confused but nevermind
that.


-- 
Paul Bone