How does Jython Thread Safety Apply to Java Swing?

Question

I'm wondering how Jython's memory model applies to creating Java Swing applications.

Most GUI code runs on the event dispatch thread in order to avoid thread interference and memory inconsistency errors.

However the Jython memory model prevents memory inconsistency errors because all variables are volatile. And thread interference is reduced by atomic operations in Jython.

This Jython concurrency chapter says, "Reading or replacing a single instance attribute" is an atomic operation. Does that also apply to Java objects used in Jython?

Does Jython's memory model change the way that concurrency can be handled in Swing applications at all?

Answer 1

Thread interference may be, to a small degree, reduced by Jython's memory model properties, but the bulk of the problems with thread interference is still there. I mean primarily the consistency of data structures. This affects almost all of the data structures containing varying numbers of items. For example, to append to an ArrayList , one might need a few operations under the hood: check the current size and allocated space, (possibly allocate more space if ran out), assign a reference at next cell past the end, and increment the size variable. Or, in a gapped buffer, inserting a character might require a few variables, that designate where the gap is, to be modified based on their previous values, as well as a large number of references to be copied if the gap has to be moved. Each operation might be atomic, but if the thread is switched out in the middle of this sequence of operations, the data structure will appear damaged from the point of view of any other thread that attempts to read or write it before the original thread comes back to finish the data structure modification operation. And Swing uses these data structures for sure, among many others.

By the way, it's a good point about atomicity. It turns out that reference assignments are also atomic operations in Java, but some care should be taken when reading long s and double s from Java, because writing these 64-bit primitives on 32-bit architectures is not necessarily atomic (ie only half might get written). In Jython, this is not a problem, because all variables are volatile .