Thread Safety

[MetalOne]

Are atomic operations thread safe in Python? Can immutable objects,
such as, strings, be created on one thread and then accessed by
another thread, without using locks?

Such operations are not guaranteed thread safe in Java due to caching
optimizations.

If someone could point me to reference documentation on this, that
would be great.

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

Are atomic operations thread safe in Python?

I don't understand the question. Atomic operations, by nature, can
either completely succeed or completely fail - otherwise it would not
be atomic. This is independent of Python.

In general, you cannot cause inconsistency of Python's internal
representation of objects by pure Python code executed in multiple
threads, so Python itself is thread-safe.

Can immutable objects,
such as, strings, be created on one thread and then accessed by
another thread, without using locks?
Yes.

Such operations are not guaranteed thread safe in Java due to caching
optimizations.

But then, in Java, strings are not immutable, no?

Regards,
Martin

 

[Alex Martelli]

:
...

But then, in Java, strings are not immutable, no?

Nope: strings ARE immutable in Java .


Alex

 

[MetalOne]

I don't understand the question. Atomic operations, by nature, can
either completely succeed or completely fail - otherwise it would not
be atomic. This is independent of Python.

But then, in Java, strings are not immutable, no?

Regards,
Martin

The problem in Java is one of visibility. Assigning
s = "hello"
does not necessarily happen if < s > is not used in the current
thread.

Likewise, another thread may see no reason to examine < s >, if < s >
has not been changed in this thread.

I found the following on a Java site.
# the language definition ensures that single memory moves concerning
32-bit values (int, etc.) are "atomic" (not interrupted)
# moving a 64-bit value (say, long) can be preempted in the middle of
the transfer operation (but it may not!)

# however, the atomicity of 32-bit moves ensures nothing about the
visibility of updated (lastly written) values (see below)

# the atomicity and correct visibility of a scalar (32- or 64-bit)
variable can be ensured by defining it volatile
# a volatile variable is always kept up-to-date and atomically loaded
from and stored into the main memory
# unfortunately, not all current Java VM implementations handle
volatile variables correctly


Java strings are immutable. There is a StringBuffer class that is
mutable.

 

[Martin v. =?iso-8859-15?q?L=F6wis?=]

The problem in Java is one of visibility. Assigning
s = "hello"
does not necessarily happen if < s > is not used in the current
thread.

I see. Python does guarantee that assignments are visible in other
threads once they have completed. It also guaranteed that the thread
either sees the old or the new value, i.e. assignments are atomic
(unless an object implements __setitem__).

Regards,
Martin

 

[ykingma]

I don't understand the question. Atomic operations, by nature, can
either completely succeed or completely fail - otherwise it would not
be atomic. This is independent of Python.

In general, you cannot cause inconsistency of Python's internal
representation of objects by pure Python code executed in multiple
threads, so Python itself is thread-safe.

For the namespaces in Jython this 'Python internal thread safety'
is handled by the Java class:

http://www.jython.org/docs/javadoc/org/python/core/PyStringMap.html

which has almost all of it public methods Java synchronized:

http://cvs.sourceforge.net/viewcvs.py/jython/jython/org/python/core/PyStringMap.java

Thinking about it: is this the Jython parallel of CPython's
Global Interpreter Lock, the famous GIL?

Regards,
Ype