On Dec 15, 2010, at 2:27 PM, Rémi Forax wrote: >> Why can't T3 happen between the synchronized block and the setUpdate call, >> and get overwritten with a T1-based decision? >> >> Rich >> > > It can. I was wrong. > setTarget() has to be in the synchronized block.
Foo; I agree. The T1 update can float into the far future and screw things up (overwriting T3). In our EG meeting this morning we decided to provide better usage guides in the javadoc. Rich, I'm going to think a while about your alternative proposal of syncTargets and swapTarget: On Dec 15, 2010, at 9:22 AM, Rich Hickey wrote: > The benefits of syncTargets and swapTarget from an API perspective are that, > given appropriate regard for the expense of syncTargets - you can't get it > wrong, the API itself delivers the coordination semantics, there is no > elaborate pattern to replicate, and the field of use is broader. Quick responses: SyncTargets would be a true global atomic transaction, with barriers in both directions to floating reads and writes. If you were willing to update the targets one at a time, but still wanted two-way barriers, you could use VolatileCallSite, and file a performance bug for JVMs to optimize the case of a stable volatile. The CAS idea does not translate well to function pointers, because they are necessarily opaque. (Function equivalence is undecidable...) The Object.equals method on them is pretty meaningless. I think you would need a double-CAS of some sort, which replaced a <descriptor, method handle> pair with a new version. I think I need a better understanding of how STM techniques are implemented on a generic JVM, and what the pain points are. -- John _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
