No, it isn't. The difference is in how mistakes are handled. With manual memory management, references through unassigned or freed pointers are mistakes, but may not generate an error immediately. In fact, it's possible the program will run fine and pass all your unit tests.

This is the situation we have now in concurrent programming: mutating a shared object without an appropriate lock is an error that probably passes silently, and it may well pass all your tests without a problem (constructing a test to reliably trigger such a big is an interesting problem in and of itself).

While you can automatically manage memory, there are other resources that still have to be managed by hand (open files spring to mind). In some cases you might be able to handle them completely automatically, in others not. In either case, Python manages things so that reading from a file that hasn't been opened is impossible, and reading from one that has been closed generates an immediate error.

The goal here is to move from where we are to a place similar to where handling files is, so that failing to properly deal with the possibility of concurrent access causes an error when it happens, not at a point distant in both time and space.

BTW, regarding the performance issue. I figured out how to implement this so that the run time cost is zero aside from the lock & unlock steps.

      <mike