[m-rev.] for review: [PATCH 1/4] Add thread_safe attribute to store procedures.
jfischer at opturion.com
Wed Jul 23 13:16:54 AEST 2014
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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the reviews