On Mon, May 27, 2013 at 4:07 PM, Ian Kelly <ian.g.ke...@gmail.com> wrote: > On Sun, May 26, 2013 at 10:36 PM, Peter Brooks > <peter.h.m.bro...@gmail.com> wrote: >> This makes complete sense - any atomic action should be atomic, so two >> threads can't be doing it at the same time. They can be doing anything >> else though. >> >> If two threads create a new object at the same time, for example, >> there's potentially the problem that they'll get the same space, so >> the object will be owned by both. To prevent this, the new object call >> should be run in only one thread. >> >> If you have two objects running their methods on their own local >> variables, then there's no potential for conflict, so there's no need >> for them to be blocked. > > That's not the way it works. [snip details]
You're actually both saying the same thing, except that Peter went for finer granularity than Ian and CPython did. CPython figures that, with a refcounted heap, there's not a lot of point having separate mutex locks for different operations. Other language interpreters have made other choices. But Peter's analysis is still correct; it's just that guarding it is simplified down to a binary state: either you have the GIL, or you don't. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
