Hi all,
In my case I don't really care which version of the data a thread sees, from the apps point of view the data is correct at the time it is fetched.
I was playing around with this idea and it's actually what the multi-version concurrency control technique was developed for* (more or less anyway).
I ended up writing http://hackage.haskell.org/package/Stasis to experiment with using an MVCC style in Haskell.
Docs aren't currently being built on hackage, trying to figure out why but have a look at the source on github to see what I was thinking


On Tue, Jan 14, 2014 at 12:23 PM, Daniel Trstenjak <daniel.trstenjak@gmail.com> wrote:

Hi AntC,

> Out of interest, is there some reason you don't mention TVar's?

The use case here seemed to be more about having shared data which is
only read most of the time and updated occasionally. So the MVar seems
to be a quite good fit for this.

> I thought they are the (modern) way to "build robust systems"
> with "different threads using forkIO"(?)

I think it really depends how your threads are accessing the shared
data. Sometimes the rollbacks of a STM might hurt you more than
waiting for the lock of a MVar.

You could use a TVar here, but you have to be aware, that your
threads might operate on outdated data - if one thread is currently
updating the data - and this might be an issue for your system.

If I'm getting it correctly, then a MVar can't be read by mutliple
threads at once, even if all threads are only reading from it.
That's an advantage of the TVar.

So thinking again about it, having only occasionally writes from
favorably only one thread and reads from multiple threads, then indeed
the TVar might be a quite good fit for this use case.


Greetings,
Daniel
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://www.haskell.org/mailman/listinfo/beginners



--
Courtney Robinson
courtney@crlog.info
http://crlog.info
07535691628 (No private #s)