Message11524

Author jeff.allen
Recipients darjus, jamesmudd, jeff.allen, stefan.richthofer, zyasoft
Date 2017-08-05.12:19:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1501935592.42.0.182764539635.issue2487@psf.upfronthosting.co.za>
In-reply-to
Content
After backing out (on a scratch repo only, so far) the sets https://hg.python.org/jython/rev/cffe5b824a21 and https://hg.python.org/jython/rev/f3458ef83e08, in the interests of #2609, I ought to find I've re-instated this issue.

Is there a sure-fire way to reproduce it?

However, I'm not sure the original problem these change sets sought to solve is what we think ... The synchronisation on PyType looks ok[1] to me, even though the two locks seem to have got entangled, according to the informative thread dump from Darjus.

In that, "Jython-Netty-Child-60" is doing a reasonable thing. It has entered the monitor on PyType.class and is patiently waiting here:
https://hg.python.org/jython/file/1a14d360dc8d/src/org/python/core/PyType.java#l1412,
to acquire the lock on the class_to_type map.

"MainThread" meanwhile is waiting to enter the monitor on PyType.class (good), but is holding the lock on on the class_to_type map (huh?). This ought not to be possible, since the monitor protects access to the class_to_type map. It looks like somehow, "MainThread" has previously exited the monitor still holding the lock.

We've a nice explanation of how that can happen in #2536.


---

[1] Actually, there *is* one place class_to_type map escapes synchronisation, and that's here:
https://hg.python.org/jython/file/1a14d360dc8d/src/org/python/core/PyType.java#l1473
I think that's an oversight. And it's not involved here.
History
Date User Action Args
2017-08-05 12:19:52jeff.allensetmessageid: <1501935592.42.0.182764539635.issue2487@psf.upfronthosting.co.za>
2017-08-05 12:19:52jeff.allensetrecipients: + jeff.allen, zyasoft, darjus, stefan.richthofer, jamesmudd
2017-08-05 12:19:52jeff.allenlinkissue2487 messages
2017-08-05 12:19:50jeff.allencreate