[m-rev.] for review: thread safe mutables (part 2)

[Julien Fischer]

On Wed, 13 Sep 2006, Peter Wang wrote:

> On 2006-08-29, Julien Fischer <juliensf at csse.unimelb.edu.au> wrote:
>>
>> Estimated hours taken: 12
>> Branches: main
>>
>> Make the get and set operations for non-constant mutables thread safe.  (The
>> get operation for constant mutables is thread safe by definition.)  The
>> source-to-source transformation for (non-constant) mutables is modified as
>> follows: we introduce four primitive operations: unsafe_get, unsafe_set,
>> lock and unlock.
>
> I think there's a problem with this.  This code no longer compiles:
>
>    :- mutable(localsupp, random.supply, random_init(0), mostly_unique,
> 	[attach_to_io_state, untrailed]).
>

I think it was an accident that it compiled in under the old scheme.

> (the important part is the mostly_unique inst)
>
> rand.m:022: In clause for `set_localsupp(in(mostly_unique))':
> rand.m:022:   in argument 1 of call to predicate `rand.unsafe_set_localsupp'/1:
> rand.m:022:   unique-mode error: the called procedure would clobber its
> rand.m:022:   argument, but variable `X' is still live.
> rand.m:022:   The goal could not be reordered, because it was impure.
> rand.m:022: In clause for `set_localsupp(in(mostly_unique), di, uo)':
> rand.m:022:   in argument 1 of call to predicate `rand.unsafe_set_localsupp'/1:
> rand.m:022:   unique-mode error: the called procedure would clobber its
> rand.m:022:   argument, but variable `X' is still live.
> rand.m:022:   The goal could not be reordered, because it was impure.

The problem here is that the set predicate has mode
(mostly_unique >> mostly_unique) but it needs to have mode
(mostly_unique >> mostly_clobbered).

My take on this is that mutables should not be allowed to have inst
(mostly-)unique.  The reference manual pretty much implies that when
it says that the set/get predicates have the modes in(I) and out(I).
(The reason this wasn't noticed under the old scheme was that everything
was implemented as foreign code.)

Unique mutables don't really make sense because you can always obtain
a second reference to them by calling the set predicate again - then
they are no longer unique.  (I guess we could make it so that calling
the set predicate made a unique copy of whatever was stored in the
mutable and returned that.)

(Mind you the fact that they are impure might mean that we should just
trust the programmmer on this one.)

For now at least, I propose the following:

(1) we change the reference manual to explicitly state that inst for
mutables may not contain unique or mostly-unique componenets.

(2) we change the compiler so that it emits and error message if
     it does.

> Also, I'm not sure what backtrackable update of [non-thread-local]
> mutables is supposed to mean in the presence of multiple threads.
> Probably nothing sane.

Almost certainly nothing sane in the absence of trailing and what the
bigger issue is how does trailing work in the presence of multiple 
threads.

Julien.
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------