Bug ID: JDK-4366698 possible deadlock on Peer object on win32 during display mode switch

Type: Bug
Component: client-libs
Sub-Component: 2d
Affected Version: 1.4.0

Priority: P1
Status: Resolved
Resolution: Fixed
OS: windows_nt
CPU: x86

Submitted: 2000-08-29
Updated: 2000-09-25
Resolved: 2000-09-25

Versions (Unresolved/Resolved/Fixed)

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.

Other
1.4.0 betaFixed

This relates to bug 4366691, but is not the same bug.  The problem described
here is due to our mechanism of synchronizing on the Peer object during
the Lock operation.  During a display mode switch, the user may experience
a hang in the application because we are deadlocked waiting for a Peer monitor
to become free when that Peer is already blocked.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin-beta FIXED IN: merlin-beta INTEGRATED IN: merlin-beta

14-06-2004

EVALUATION Suggested fix worked - we now synchronize on a CriticalSection object associated with each SurfaceData.

11-06-2004

SUGGESTED FIX We should synchronize on a different object, possibly a new CRITICAL_SECTION object that resides in the wsdo structure; that should provide the same functionality as before (allowing different surface data objects to operate concurrently but synchronizing different threads through the same wsdo object when locking the same surface), but would avoid dependencies on Java objects that may be blocked.

11-06-2004

Relates :	JDK-4345586 - Rendering incorrect after switching display modes (win32 only)
Relates :	JDK-4366691 - deadlock condition on win32 during display mode switch