No, that is not enough. If you want to implement atomicity for operations that touch multiple objects, a simple mutex-per-object approach just won't cut it. If you start holding multiple mutexes at once, there will be deadlocking if they are not locked in a consistent order.

Not to mention that if every object has a mutex associated, the performance will be horrible. Even if the mutexes are not contended, there will be so many atomic compare and swap operations that the interprocessor memory bus will simply die.

If your solution would work, every method in Java would be synchronized by default.

I agree with your points on performance, but it's worth noting that they apply to STM as well: if you make the atomic regions too numerous and coarse grain, the compare-and-swap operations will kill performance.

That's essentially what Jython does. He discusses why he does not want to go in that direction in the article.

He says that it would be much work and hard to do manually.

But I think you can add such a behavior in an automatic way.

It is also stated why doing that automatically is unfeasible.

The only issue stated about that is the possibility of deadlocks when done in an automatic way.

However, I claim that you can also do it in an automatic way and avoid deadlocks at the same time.

In order to avoid dead locks you need to be aware of the language semantics, which you are not if you automatically transform the interpreter.

What I mean is that even without knowing that, you can still do it in an automatic way.

E.g., like this: https://github.com/albertz/automatic_object_locking/blob/mas...

You are assuming that all the objects that will be accessed are known up front, before any one of them is accessed. Is that what happens in Python?