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.
EVALUATION
At one stage we create a new placeholder entry and then do a final check in case the target class was
loaded in parallel. If it was we simply return that. But we don't remove the new placeholder, or rat
her we don't call remove_seen_thread on the placeholder entry. This causes a problem for threads that
have entered the wait() loop. Here's an attempted description of the failure scenario:
- thread A is doing the actual load and has created a placeholder entry
- thread B sees the placeholder and starts doing the wait()
- thread C sees the placeholder and blocks on the SD lock prior to the code that will do the wait()
- thread A completes the load, removes the placeholder and does a notifyAll
- thread B returns from wait(), escapes the wait-loop because there's no placeholder with a load-in-
progress, creates a new placeholder entry, then finds that A already loaded the class and so returns
it
- thread C gets the SD lock, sees the placeholder created by B and so does a wait() for which there
is no direct notify. Even if an unrelated notify occurs, thread C continues to see B's placeholder an
d so keeps on looping and wait()ing forever.