[Python-Dev] New PEP: 319

[Michel Pelletier]

Hi Skip!

>     Jack> There will always be situations where you want to lock multiple
>     Jack> objects,
>
>     Michel> Can you be more explicit?  I'm not sure I understand.
>
> I have a multi-threaded XML-RPC server which, among lots of other bits of
> data maintains some "top 50" data (top 50 cities searched for, top 50
> performers searched for, etc).  Update time for that data is very fast
> relative to much of the other data maintained by the server.  Rather than
> create a lock for each of the various "top 50" objects, I simply created a
> single top50_lock object and acquire and release it around manipulation of
> any of the various bits related to that stuff.  Having a single lock means
> my code is simpler at the possible extra cost of only allowing a single
> thread into a larger chunk of code.  OTOH, had I created multiple locks,
> performance might actually have gotten worse due to lock
> acquisition/release
> overhead.
>
> Obviously I could have done things differently.  I could have coalesced
> all
> the top 50 data into a single object and locked it or created a separate
> lock for each item.

    synchronize item:

would create a (hidden) lock for each item for you.  Wouldn't this solve
your problem of no two threads changing one item?  or do changes to any
one top 50 item *require* locking all 50?  If they are independent that
this is exactly the purpose PEP 319 serves.

>  Still, I agree with Jack that there are plenty of
> situations where you use one lock to lock multiple objects.  (Consider the
> Python GIL as another example. ;-)

Isn't the interpreter one object in this case?  Does the GIL lock anything
else other than the interpreter?

-Michel