threads: not locking read-only objects

[Jon Perez]

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?

[Christopher T King]

Re: threads: not locking read-only objects

On Sat, 7 Aug 2004, Jon Perez wrote:
[color=blue]
> 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?[/color]

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.

[Jon Perez]

Re: threads: not locking read-only objects

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']="timeoflogi n" # 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:
[color=blue]
> On Sat, 7 Aug 2004, Jon Perez wrote:
>
>[color=green]
>>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?[/color]
>
>
> 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.
>[/color]

[Heiko Wundram]

Re: threads: not locking read-only objects

Am Samstag, 7. August 2004 04:58 schrieb Jon Perez:[color=blue]
> whoison['username']="timeoflogi n" # to add someone new
>
> del whoison['username'] # to remove someone who's logged out
>
> Do the above count as atomic?[/color]

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.
[color=blue]
> 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?[/color]

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.