While reading code I noticed a small race in initBlockedOn in AbstractInterruptibleChannel.  This code attempts to get an accessible Method pointing at Thread.blockedOn without doing any synchronization.  The code as executed should be idempotent so that mostly seems ok.  The problem is that the code publishes the method in blockedOnMethod before it has call setAccessible on it.  This means that another thread could potentially try to use it before the flag was set.  It's extremely unlikely that this could happen but it's still possible.  There are two potential fixes.  One is to put the value into local, call setAccessible and then put it into the static.  I'm still not sure whether any of this code is safe with respect to the Java memory model since no synchronization occurs between the initializing and using threads and the accessible field by definition isn't final so it doesn't enjoy the funny semantics.  The other fix is to avoid reflection all together and use the sun.misc.SharedSecrets mechanism to bind to the needed method directly.  This in general seems better since it avoids the reflective initialization overhead.  This would also address 4653090 which complains about the allocation required for the Method.invoke call.
###@###.### 2005-03-22 23:16:39 GMT