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)