JDK-4366691 : deadlock condition 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
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
Related Reports
Relates :  
JDK-4366698 - possible deadlock on Peer object on win32 during display mode switch
Relates :  
JDK-4265501 - Windows regression: Deadlock between printing code and graphics disposal
Relates :  
JDK-4045781 - exposed/damaged canvases don't always update correctly on win32
Relates :  
JDK-4345586 - Rendering incorrect after switching display modes (win32 only)
Relates :  
JDK-4264410 - MultiDitherTest fails with assertion
Description
When switching display modes on win32 (which the user can do via the 
Display Settings dialog box) there is the potential for a deadlock between
the rendering thread and the Windows thread.
Comments
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 (in Comments section) not quite right. Both the overhead and functionality of requesting DC locks from the event thread make that solution unworkable. Instead, we removed the source of this deadlock, which was in getting the dclock and releasing the DC in an InvalidateSD call (which might be called on the event thread). Now we funnel all DC releases through the same channel (in Win32SD_GetDC) and no longer have to lock during the InvalidateSD call. We create a new CriticalSection object specifically for locking around manipulation of a list of DC's to be released (but note that we don't keep the lock when calling into another thread, which is the case for a SendMessage call to actually released the DC).
11-06-2004