By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,361 Members | 1,700 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,361 IT Pros & Developers. It's quick & easy.

threads: not locking read-only objects

P: n/a
Is it safe to not put a lock on an object if it will always
be read-only in other threads and will only ever be written to
in just one and always the same one thread?
Jul 18 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
On Sat, 7 Aug 2004, Jon Perez wrote:
Is it safe to not put a lock on an object if it will always
be read-only in other threads and will only ever be written to
in just one and always the same one thread?


Only if the writes are guaranteed to be atomic: if the object is ever
temporarily left in an inconsistent state by the writer (due to a thread
switch), the readers will read inconsistent data. If you are sure this
can't happen, then yes, doing so is safe.

Jul 18 '05 #2

P: n/a
Hmmm... here's what's going on. I have a dictionary of
logged in users called 'whoison' that's updated in the main
thread (and only in the main thread) with a:

whoison['username']="timeoflogin" # to add someone new

and

del whoison['username'] # to remove someone who's logged out
Do the above count as atomic?
The worker threads do the following read-only operation:

for x in whoison:
print x,whoison[x]

Looking at the read-only code though I just realized
something.... if a dictionary entry in 'whoison' is deleted
by the main thread while the 'for x in whoison' is executing
then what would happen?

Looks like I'm going to need a lock after all even for the
read-only operations...?

Christopher T King wrote:
On Sat, 7 Aug 2004, Jon Perez wrote:

Is it safe to not put a lock on an object if it will always
be read-only in other threads and will only ever be written to
in just one and always the same one thread?

Only if the writes are guaranteed to be atomic: if the object is ever
temporarily left in an inconsistent state by the writer (due to a thread
switch), the readers will read inconsistent data. If you are sure this
can't happen, then yes, doing so is safe.

Jul 18 '05 #3

P: n/a
Am Samstag, 7. August 2004 04:58 schrieb Jon Perez:
whoison['username']="timeoflogin" # to add someone new

del whoison['username'] # to remove someone who's logged out

Do the above count as atomic?
Yup, both of them are atomic. But: If you use different dictionary keys than
strings, you're in for a little surprise, as __hash__ing an object can cause
Python to be called, which might be suspended by a thread switch.

The dictionary object will still be in perfect order (it'll never be in an
inconsistent state), but the key reference won't be in the dictionary yet.
for x in whoison:
print x,whoison[x]

Looking at the read-only code though I just realized
something.... if a dictionary entry in 'whoison' is deleted
by the main thread while the 'for x in whoison' is executing
then what would happen?


Now, this is something different. You can easily try what happens by doing the
following:

whoison = {"heiko":"at home","heiko2":"at work"}
for x in whoison:
print x, whoison[x]
del whoison[x]

Traceback (most recent call last):
File "<stdin>", line 1, in ?
RuntimeError: dictionary changed size during iteration

That's the same exception you'll get when another thread changes the python
dict while you're iterating over it.

What you might do:

# The following makes a static copy of the keys of the dictionary.
for x in whoison.keys():
try:
val = whoison[x]
except KeyError:
continue
print x, val

Or just acquire a thread lock before processing the dictionary, which might
actually be the easiest solution. ;)

Heiko.
Jul 18 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.