> nobody can enter the cache while you hold the lock and so the contention
is
> large, right now we have contention on the ctx only so much finer
grained...
> again we will commit right now, with the understanding of the old bug as
> well

Ok, I just saw the new locking. A bit confused here, since we have discussed
this so many times. You are aware that the current locking is theoretically
flawed since the acquired context can change id before we lock on it? Since
you do it in two separate synch blocks there is the possibility that someone
gets in between and changes the id of the context. You may not see it in
tests, but theoretically the problem is there, and which is the only reason
why we had the double locking scheme on the cache AND the ctx.

I can see why it works now (mostly luck) but I would not sleep well with
this scheme. Am I missing something, or do you see the current code as
temporary and I should not worry so much?

/Rickard



Reply via email to