[Python-ideas] Concurrent safety?
mwm at mired.org
Mon Oct 31 22:06:56 CET 2011
On Mon, Oct 31, 2011 at 1:47 PM, Jim Jewett <jimjjewett at gmail.com> wrote:
> On Sun, Oct 30, 2011 at 11:11 PM, Mike Meyer <mwm at mired.org> wrote:
> > immutable types will work well in this environment exactly as is.
> If there isn't a way to generate this list automatically, it is the
> equivalent of manual memory management.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas