[prev in list] [next in list] [prev in thread] [next in thread] 

List:       haskell-cafe
Subject:    Re: [Haskell-cafe] Efficient mutable arrays in STM
From:       David Barbour <dmbarbour () gmail ! com>
Date:       2011-10-31 1:31:32
Message-ID: CAAOQMSv-u6azGJMA8RDAt=2i4d9Lguc56XrXFkmc=kj2BHfi3w () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On Sun, Oct 30, 2011 at 6:20 PM, Ben Franksen <ben.franksen@online.de>wrote:

> According to the original STM paper the implementation does an equality
> test, albeit only for pointer equality.


It strikes me as bad form to depend on characteristics of `the
implementation`.



An incremented integer would probably be ok, (no need to evaluate it,

since the closure is newly allocated, thus a new object)


Evaluation would be necessary to avoid a subtle space-leak with laziness
semantics. The size of the closure is potentially linear with the number of
allocations.



A little more on the safe side is a new TVar
>

That works too.

Regards,

Dave

[Attachment #5 (text/html)]

<br><br><div class="gmail_quote">On Sun, Oct 30, 2011 at 6:20 PM, Ben Franksen <span \
dir="ltr">&lt;<a href="mailto:ben.franksen@online.de">ben.franksen@online.de</a>&gt;</span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;"> <div class="im">According to the original STM paper \
the implementation does an equality</div> test, albeit only for pointer \
equality.</blockquote><div><br></div><div>It strikes me as bad form to depend on \
characteristics of `the implementation`.</div><div><br></div><blockquote \
class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; \
margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); \
border-left-style: solid; padding-left: 1ex; ">  </blockquote><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex;">An incremented integer  would probably be ok, (no need to \
evaluate it, </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex;"> since the closure is newly  \
allocated, thus a new object)</blockquote><div><br></div><div>Evaluation would be \
necessary to avoid a subtle space-leak with laziness semantics. The size of the \
closure is potentially linear with the number of allocations.</div> \
<div><br></div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: \
0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; \
border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; \
">  </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex;">A little more on the safe side is \
a new TVar<br></blockquote><div><br></div><div>That works too.  </div><div> \
<br></div><div>Regards,</div><div><br></div><div>Dave</div></div>



_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[prev in list] [next in list] [prev in thread] [next in thread]