Askemos Forum

Starting from some pstore problems we came about to discuss, which operation are / should be defined to be atomic.

This discussion doesn't take place here. But since I have huge problems getting evolution work over cfs, I'm tired of the overfull mail box.

(BTW: How does it actually come that fnctl(2) is some times possible and fails a few minutes later?)

On 8/13/06, Joerg F. Wittenberger <Joerg.Wittenberger@softeyes.net> wrote:
> Donovan,
>
> synchronous commit is unbearable slow.
>
> I found a use of copy-info-pstore and based on wild guess I wrote:
>
> (define (pstore-make-copy-in ps)
>   (lambda (obj)
>     (copy-into-pstore (default-allocation-area ps) obj)))
>
> New pairs, which go exactly into the hash table as discussed before,
> are now pushed through the resulting function (a pair from "(cons #f
> #f)" actually to defer the actual copy-in of the value itsef).
>
> But this looks - to mee - as if I had replaced one race condition with
> another one (though the second one seems not yet to appear): is it
> permitted to call copy-into-pstore from one thread while another one
> is doing the commit?  Or may these clobber each others data?

They copy-into-pstore is atomic with respect to the threads system, so
it will complete before the commit going on in another thread can do
more work.  Of course, copying the object into the store will dirty a
page or two, and so will create more work for the commit thread --
there is a potential for starvation if there are hoards of threads
copying stuff into the store and only one thread trying to commit!

> I just typed "Let alone that I could no longer reproduce the bug
> probably related to the theory of the pair beeing updated while moved,
> I still have simillar problems:".  Now the bug reappeared, so the
> solution above doesn't always work, but mitigates the effect greatly.
>
> However among the values hanging from my hash table entries, there's
> another hash table storing vectors of (wiki link) lists.  When I
> update this has table ~200 times a single commit takes place in
> another thread.  Once in a while entries in that table disappear.

I still can't quite understand why the entries disappear.  I can see
why an entry might be out of date.

What kind of hash tables are these?  Are they <generic-table>s?  If
so, that might explain it because a <generic-table> does not have the
same atomicity properties (because generic tables have to call
arbitrary scheme functions to compute hash values and test equality,
they can't run atomically with respect to the threads system...)

> Discovering copy-into-pstore however suggests an entirely different
> approch.  Instead of the central ex-or asynchronous commit I could
> just copy-into-pstore value by value.  How would I commit just
> everything reachable from something else but the root object of the
> pstore?

Unfortunately, there isn't an easy way to do that.  I have sometimes
wanted that myself, for essentially just this reason.

--
-- Donovan