Hi, Anton.
The fix looks good.
On 22.09.2014 19:00, Anton V. Tarasov wrote:
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.
--
Best regards, Sergey.
