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

[Julien Fischer]

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.


> (Of course
> someone can use a uniquness cast to create trouble for themselves but
> that's
> not a new problem.)
>

The uniqueness casts do have "unsafe_" in their names for a reason ...


> > On a related note: I've been using the impure mutvar module in the
> > standard library quite a bit -- how does everyone feel about making that
> > into a publicly documented part of the standard library (after a
> > suitable documentation cleanup)?
>
> I'm fine with that, the usual story applies about putting a large notice
> above it about thread safety, in addition to the impurity as the mutvar
> operations themselves arn't thread safe.


Sure.

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