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 longs and doubles from Java, because writing these 64-bit primitives on 32-bit architectures is not necessarily atomic (i.e. only half might get written). In Jython, this is not a problem, because all variables are volatile.
