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

Julien Fischer jfischer at opturion.com
Wed Jul 23 16:48:00 AEST 2014


On Wed, Jul 23, 2014 at 3:58 PM, Paul Bone <paul at bone.id.au> wrote:

> 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.
>

It simple enough:

- thread safety is an issue for mutvars attached to the I/O state because
  the I/O state can be split by a call to spawn and in principle both
threads
  can access the mutavar.

- thread safety is not an issue for mutvars attached to other states since
  the states must be unique and cannot be split by a call to spawn.
  (The inst of the closure passed to spawn prevents this.)

Cheers,
Julien.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20140723/319a2b97/attachment.html>


More information about the reviews mailing list