[Haskell-cafe] Efficient mutable arrays in STM

[Antoine Latter]

As far as I lnow the function 'unsafeIOToSTM' is not transactional in nature
- IO actions will be performed immediately and are not rolled back, and are
then re-performed on retry.
On Oct 25, 2011 12:49 PM, "Ben Franksen" <ben.franksen at online.de> wrote:

> I have an application in mind where concurrent access to large arrays (up
> to
> millions of elements) of mostly small elements (Int or Double) is common.
> Typical access patterns would be chunk-wise, i.e. reads or writes from
> index
> n up to index m. Imagine stuff like images, scientific data, etc.
>
> All this suggests that Control.Concurrent.STM.TArray, in its current
> implementation, is not appropriate. Quoting the docs:
>
> "It is currently implemented as Array ix (TVar e), but it may be replaced
> by
> a more efficient implementation in the future (the interface will remain
> the
> same, however)."
>
> An array of TVars is certainly *much* too inefficient for what I have in
> mind w.r.t. both memory and cpu time. In fact I had already decided to use
> Data.Vector.Unboxed from the vector package.
>
> I see that Data.Vector.Unboxed.Mutable provides
>
>  slice :: Unbox a => Int -> Int -> MVector s a -> MVector s a
>    Yield a part of the mutable vector without copying it.
>
> which is almost what I need... Can I use this together with unsafeIOToSTM
> internally inside a library to provide shared transactional access to an
> IOArray? The docs warn that using unsafeIOToSTM is (obviously) "highly
> dangerous", but for what I have in mind the listed problems are not an
> issue:
>
>  * running the IO code multiple times is ok
>  * aborting is ok, too
>  * inconsistent views are ok, too
>
> The main question is: does the STM transaction actually "see" that I
> changed
> part of the underlying array, so that the transaction gets re-tried? Or do
> I
> have to implement this manually, and if yes: how?
>
> Has anyone done something like that before? (If you tried this and found it
> doesn't work, please tell me, it would save me a lot of work repeating the
> effort).
>
> Is someone working on providing a more efficient version of TArray?
>
> Would it help if I said I'd be a happy user of a better TArray? ;-)
>
> If what I sketched above is infeasible (I would not be surprised if it was,
> I haven't yet spent much effort trying it out), what other options do I
> have? Is there an internal API for the STM stuff, i.e. a C header file or
> something which would make it possible to add efficient TArrays?
>
> Or should I use a high-level approach, something like a Data.Sequence.Seq
> of
> medium sized chunks (TVar (IOVector e))?
>
> Any comments are highly appreciated!
>
> Cheers
> Ben
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20111025/c4eb7846/attachment.htm>