Here's the detail for Jython: https://jython.readthedocs.io/en/latest/Concurrency/

Skip down to "thread safety"

> They need some form of locking around Python objects accessed from multiple threads, since Python has no ownership model.

"Ownership models" are not a given. C++ has no "ownership model" and it doesn't lock around objects. Multi-threading users are just given the synchronization primitives and are expected to manage their own solutions.

The same is true in Python: https://docs.python.org/3/library/threading.html#lock-object... - in fact, if you're using objects simultaneously from multiple threads without using some sort of locking scheme, you're probably already in trouble...

The main thing that's keeping the GIL around is the reference-counting garbage collector. If your python implementation uses its own GC mechanism, it doesn't have this problem.

It's not difficulty. It's been done experimentally - exactly as you say. They use locks around everything.

What's hard is doing it without dumpstering single thread performance.

Most languages with proper multithreading that I've used don't have an ownership model. Most the the standard library collection types are explicitly not thread safe, and then there's separate concurrent versions for if you're writing multithreaded code. And you're given locking/mutex primitives if you want to roll your own stuff.