Callsite invalidation requirements?
mroos at roos.com
Tue Feb 14 19:34:16 PST 2012
> From: Charles Oliver Nutter
> As above, volatility is not important if threads are actively
> guarding. It only becomes a problem if you expect threads to reflect
> call site changes automatically without doing any of their own guard
My question is if I do not do a sync operation when do the callsites
get the new values. Its always referenced to threads so are the targets
cached relative to a thread? If this is true then new threads will always
get new targets. Of course if I use a pool or a timer I would guess that
the targets may never update. So far each I get a new thread for each
request and am not doing any sync and it works. But....
> Specifically, I was looking up the
> method before I got the class's SwitchPoint...which is exactly the
> wrong order. There were cases where I could end up associating the
> looked-up method with a newer SwitchPoint, effectively caching forever
> the wrong method.
I can see this as an interesting problem. One could presume that there is
possibly a thread between the switchPoint and the fallback when the switch
fires. So when it goes a get the target it could be the new target which
it then pollutes. So the switchPoint needs to relace itself and the
when it fires so the old fallback updates the one being dropped and not
new. I have callsite-switch-callsite as it is but I need to make sure
the second call site is what is passed to the fallback and not the first
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mlvm-dev