|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.
then check the id upon entering the ctx lock
if ok go on
if not get ctx again
100% safe
marc
PS: Also when you enter the second block you go to wait and get ctx again...
Plus frankly the possibility of that happening doesn't prevent me from
sleeping at night :))) (the 2 blocks are contiguous AND when you enter and
go to sleep you get the ctx again) so it would need to be a thread that does
the whole id changing thing (like remove ctx) meaning the whole the
invocation layer while one is stuck at
"
sync(cache)
}
//right here, stuck while the other does the *whole* invocation layer
sync(ctx) {
}
again remember that as soon as the thread enters the second it means you get
a ctx again (you go to wait) and that is safe, I really don't see a problem
with that, probability 1.10^-9.
|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
|
|
|
|
