[m-dev.] thread safe mutable updates

Julien Fischer juliensf at csse.unimelb.edu.au
Tue Aug 15 15:14:51 AEST 2006


On Tue, 15 Aug 2006, Ralph Becket wrote:

> Julien Fischer, Monday, 14 August 2006:
>>
>> Peter Wang recently pointed at that the current "thread_safe" mutables
>> are really not; further more there is currently no way of atomically
>> updating the value of mutable based on its present value.
>>
>> e.g. the following cannot be carried out as an atomic operation.
>>
>> 	...
>> 	get_varname(X0, !IO),
>> 	X = Transform(X0),
>> 	set_varname(X, !IO),
>> 	...
>>
>> The problem with the above is that it is possible for another thread to
>> change the value of varname while Transform is being executed.
>>
>> I have just posted a diff that removes the existing (broken) thread_safe
>> mutable support.  Peter and I have discussed two proposals for extending
>> mutables in the presence of threads:
>>
>> (1) add a `thread_local' attribute that allows for (optional) thread-local
>>     mutables.
>>
>> (2) for mutables that are truly global (and hence potentially shared
>>     between threads) add a new mutable operation `update' that allows
>>     the value of the mutable to be atomically updated.
>
> What about (3) just require users to use a mutex to gain access to a mutable
> with transaction semantics?
>
> I think that is cleaner than (1) or (2).

In the case of mutables that are attached to the I/O state I think (3)
is probably going to be overkill in most cases.  We could make the 
mutables export access to their locking mechanism.

 	:- mutable(varname, ...

would create:

 	:- impure lock_varname is det.
 	:- impure unlock_varname is det.

That way if you didn't want to use the compiler generated update method
you could build your own.  (We will be creating the above locking 
predicates anyway, in order to implement the update predicates, so it's
just a matter of giving them a user-friendly name.)

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



More information about the developers mailing list