On 9/22/14 5:52 PM, Sergey Bylokhov wrote:
Hi, Anton.
I think after the fix, getFlag+setFlag are not atomic anymore in the
revalidate().
I assumed revalidate() is called on EDT in case of pure Swing, and may
be called from JavaFX App Thread in case of swing/javafx interop only.
However, I didn't take into account swing/awt mixing where this
particular method is "allowed" to be called from non-EDT threads.
In this case, you're right, the getFlag+setFlag, being called on two
concurrent threads, are not synchronized.
Ok, I'm still trying to keep the scheme lock-free. What do you think of
the following approach?
http://cr.openjdk.java.net/~ant/JDK-8058870/webrev.1
We're eliminating the flag and using AtomicBoolean instead.
The "flags" field is private. REVALIDATE_RUNNABLE_SCHEDULED is only used
for this single case. So, the only concern is serialization, for which I
reinitialize the new field in readObject. At the worst case, we will
have maximum two revalidate runnables in the queue, which shouldn't hit
performance any noticeably (and as far as I understand, this code cares
about performance only).
Thanks,
Anton.
On 22.09.2014 17:36, Anton V. Tarasov wrote:
Hello,
Please review a fix:
https://bugs.openjdk.java.net/browse/JDK-8058870
http://cr.openjdk.java.net/~ant/JDK-8058870/webrev.0
A deadlock has been revealed on MacOS X with JFXPanel involved in an
app launched via JNLP. Find more details in jira, please.
Thanks,
Anton.
