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

[Paul Bone]

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.  (Of course
someone can use a uniquness cast to create trouble for themselves but that's
not a new problem.)


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


-- 
Paul Bone