JDK-6607230 : D3D: infinite wait is possible in D3DScreenUpdateManager.runUpdateNow()
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6u5
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-09-20
  • Updated: 2010-10-14
  • Resolved: 2007-10-09
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6u10 b05Fixed
Description
It is possible to get into an infinite wait when using
D3DScreenUpdateManager.runUpdateNow().
Comments
SUGGESTED FIX http://sa.sfbay.sun.com/projects/java2d_data/6u5/6607230.1
21-09-2007
EVALUATION If the timing is just right such that the following sequence of events happens: - there's a single onscreen surface created at some point, then disposed of (invalidated) at the same time as.. - .. another thread calls Toolkit.sync() which ends up calling D3DScreenUpdateManager.runUpdateNow() We could end up with the updater thread missing the notify() from runUpdateNow() and sleeping forever in runLock.wait(). There's a related problem in using runLock.notify() - we should be using notifyAll() since there may be multiple threads calling sync() and waiting for update to finish. Just using notify() will wake up one of those threads, not necessarily the screen updater thread. And there was an issue with the ordering of invalidating/replacing onscreen surfaces in WComponentPeer.replaceSurfaceData() pointer by one of the reviewers - we typically first replace teh surface, then invalidate the old one. In WComponentPeer the order was reversed because we needed to remove the d3d onscreen surface from the list of managed surfaces. This could be done by other means, avoiding issues with creating a graphics with already invalidated surface.
20-09-2007