Hi.<div>That´s fine. I missed an implementation of a  persistent b-tree in haskell. I planned to do my own, but it is not trivial task.</div><div><br></div><div>how the IO and STM is managed? . The serialization- deserialization is automatic  or programmer must write the cached blocks?  (i suppose that the block reads are automatic on data requests). </div>


<div><br></div><div>The state in the disk is coherent at every moment?. I mean, if there is a program failure, the state in the btree in the file would be coherent?</div><div><br></div><div>For example, if I write two TVars in two different blocks within the same STM transaction, do I have the guarantee that either both updated values will be in the file storage or none of them  will be?</div>


<div><br></div><div><br></div><div>Alberto</div><div><br></div><div><br><div class="gmail_quote">2012/10/30 Johan Brinch <span dir="ltr">&lt;<a href="mailto:brinchj@gmail.com" target="_blank">brinchj@gmail.com</a>&gt;</span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Greetings Haskellers,<br>
<br>
We are pleased to announce this new package, featuring a concurrent<br>
b-tree developed as part of our master&#39;s thesis on backup systems. The<br>
package features code related to STM, caching, QuickCheck and of<br>
course concurrency and parallelism.<br>
<br>
And it&#39;s also on Hackage:<br>
<a href="http://hackage.haskell.org/package/btree-concurrent" target="_blank">http://hackage.haskell.org/package/btree-concurrent</a><br>
<br>
In case the build fails on Hackage and the documentation doesn&#39;t work,<br>
it&#39;s also available here:<br>
<a href="http://hindsight.dk/doc/html/btree-concurrent" target="_blank">http://hindsight.dk/doc/html/btree-concurrent</a><br>
<br>
<br>
Credits to Thomas Conway of Melbourne University, for discussions<br>
related to the implementation, and to our supervisor Ken Friis Larsen<br>
of University of Copenhagen.<br>
<br>
<br>
And now, the description of the package:<br>
=====<br>
<br>
A backend agnostic, concurrent BTree with relaxed balance[1] written<br>
in Haskell using a mix of IO operations and pure STM.<br>
<br>
Although the code does work, it is neither production-ready nor complete.<br>
<br>
Features include:<br>
* Caching: While nodes are periodically saved on persistent storage<br>
(e.g. disk) they are cached in-memory during operations.<br>
<br>
* Live flushing: It is possible to save the current version of the<br>
tree to disk and run modifying operations at the same time. The nodes<br>
are updated buttom-up to ensure a valid tree in the case of a crash.<br>
<br>
* Backend agnosticism: A simple API is used as an abstraction for the<br>
persistent storage.<br>
<br>
* Verification: The test-suite uses QuickCheck to compare the trees<br>
behaviour to that of Data.Map.<br>
<br>
Deficients include:<br>
* Memory greedy. Nodes are not stored in a compact fashion and are<br>
constantly being serialised/deserialised.<br>
<br>
* findMin and findMax are incomplete and may fail (see the TODO for details).<br>
<br>
* The implementation does not parallelise well.<br>
<br>
<br>
[1] B-trees with relaxed balance, K. S. Larsen &amp; R. Fagerberg,<br>
Parallel Processing Symposium, 1995. Proceedings., 9th International<br>
<span><font color="#888888"><br>
--<br>
Johan Brinch &amp; Morten Brøns-Pedersen<br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">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>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>Alberto.<br>
</div>