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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4