How does IronPythons threading model relate to CPythons with respect to object operations?
CPython has a Global Interpreter Lock, and it interprets opcodes for operations on primitive types atomically. IronPython also ensures operations on primitive types are atomic (for example, inserting into a list or removing an item at a specific index). However, IronPython’s in-place addition operations (for example, “l = []; l += 2,3,4”) are not atomic, so if two threads perform this operation, “l” could end up with interleaving values. Furthermore, IronPython looks up an operation’s implementation method atomically and then invokes the method atomically. Between the time of the look up and the invoke, another thread could execute that replaced the definition of the operation, and the first thread would invoke the old definition it found. If a program’s behavior needs to be guaranteed across this sort of scenario, your program should be ensuring this level of thread safety; the CPython specification makes no guarantees in this situation either.
