[ghc-steering-committee] Replace atomicModifyMutVar# (#149), recommendation: accept

[Ryan Newton]

My only initial reservation was it being subsumed by mutable structs.  But
if it's small, self contained, already implemented, and doesn't increase
complexity -- why not?





On Thu, Jul 5, 2018 at 3:03 PM Simon Marlow <marlowsd at gmail.com> wrote:

> On 5 July 2018 at 16:24, Simon Peyton Jones <simonpj at microsoft.com> wrote:
>
>> It sounds good to me – I have not dug into the details but it seems to
>> have had enough scrutiny.
>>
>>
>>
>> Note that it *replaces one primop with another*, with the old one being
>> re-defined as an ordinary function for back-compat.   The proposal does not
>> just add an extra primop.  Right?
>>
>>
> Yes, that's right.
>
> Simon
>
>
>>
>>
>> I’m supportive, albeit not very well informed.
>>
>>
>> Simon
>>
>>
>>
>> *From:* ghc-steering-committee <
>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Simon Marlow
>> *Sent:* 04 July 2018 10:19
>> *To:* ghc-steering-committee at haskell.org
>> *Subject:* [ghc-steering-committee] Replace atomicModifyMutVar# (#149),
>> recommendation: accept
>>
>>
>>
>> https://github.com/ghc-proposals/ghc-proposals/pull/149
>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F149&data=02%7C01%7Csimonpj%40microsoft.com%7Caf6991e741df405fd5a308d5e18f477f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636662927862631135&sdata=biPMT2Nj9w7jJHUSdHU3eaHMS9wOzIbm7w%2B6txXLpeE%3D&reserved=0>
>>
>>
>>
>> This proposal is essentially an optimisation to the atomicModifyMutVar#
>> primitive. I won't repeat the details here, but it amounts to moving one of
>> the thunks produced by atomicModifyMutVar# out of the primop and into the
>> atomicModifyIORef wrapper. The advantage is that in the case of the strict
>> version of the wrapper, atomicModifyIORef', this extra thunk is eliminated
>> entirely, rather than being created by the primop and then immediately
>> evaluated by the wrapper.
>>
>>
>>
>> I propose we accept the proposal to add the new primop in section 2.1,
>> along with the straightforward additions proposed in sections 2.2 and 2.3.
>> (the old primop will be removed, but can be defined in GHC.Exts  as a
>> wrapper around the new primop for backwards compat)
>>
>>
>>
>> However, the additions to the Data.IORef library should be considered by
>> the libraries committee separately. (there are naming issues to be resolved
>> in particular).
>>
>>
>>
>> Cheers
>>
>> Simon
>>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180709/95e48235/attachment.html>