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. 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. ;-)
Skip
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