<p>As far as I lnow the function &#39;unsafeIOToSTM&#39; is not transactional in nature - IO actions will be performed immediately and are not rolled back, and are then re-performed on retry.</p>
<div class="gmail_quote">On Oct 25, 2011 12:49 PM, &quot;Ben Franksen&quot; &lt;<a href="mailto:ben.franksen@online.de">ben.franksen@online.de</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have an application in mind where concurrent access to large arrays (up to<br>
millions of elements) of mostly small elements (Int or Double) is common.<br>
Typical access patterns would be chunk-wise, i.e. reads or writes from index<br>
n up to index m. Imagine stuff like images, scientific data, etc.<br>
<br>
All this suggests that Control.Concurrent.STM.TArray, in its current<br>
implementation, is not appropriate. Quoting the docs:<br>
<br>
&quot;It is currently implemented as Array ix (TVar e), but it may be replaced by<br>
a more efficient implementation in the future (the interface will remain the<br>
same, however).&quot;<br>
<br>
An array of TVars is certainly *much* too inefficient for what I have in<br>
mind w.r.t. both memory and cpu time. In fact I had already decided to use<br>
Data.Vector.Unboxed from the vector package.<br>
<br>
I see that Data.Vector.Unboxed.Mutable provides<br>
<br>
  slice :: Unbox a =&gt; Int -&gt; Int -&gt; MVector s a -&gt; MVector s a<br>
    Yield a part of the mutable vector without copying it.<br>
<br>
which is almost what I need... Can I use this together with unsafeIOToSTM<br>
internally inside a library to provide shared transactional access to an<br>
IOArray? The docs warn that using unsafeIOToSTM is (obviously) &quot;highly<br>
dangerous&quot;, but for what I have in mind the listed problems are not an<br>
issue:<br>
<br>
 * running the IO code multiple times is ok<br>
 * aborting is ok, too<br>
 * inconsistent views are ok, too<br>
<br>
The main question is: does the STM transaction actually &quot;see&quot; that I changed<br>
part of the underlying array, so that the transaction gets re-tried? Or do I<br>
have to implement this manually, and if yes: how?<br>
<br>
Has anyone done something like that before? (If you tried this and found it<br>
doesn&#39;t work, please tell me, it would save me a lot of work repeating the<br>
effort).<br>
<br>
Is someone working on providing a more efficient version of TArray?<br>
<br>
Would it help if I said I&#39;d be a happy user of a better TArray? ;-)<br>
<br>
If what I sketched above is infeasible (I would not be surprised if it was,<br>
I haven&#39;t yet spent much effort trying it out), what other options do I<br>
have? Is there an internal API for the STM stuff, i.e. a C header file or<br>
something which would make it possible to add efficient TArrays?<br>
<br>
Or should I use a high-level approach, something like a Data.Sequence.Seq of<br>
medium sized chunks (TVar (IOVector e))?<br>
<br>
Any comments are highly appreciated!<br>
<br>
Cheers<br>
Ben<br>
<br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div>