If print s
is replaced by print >>sys.stderr, s
then the effect vanishes.
import random, sys, time
import threading
lock = threading.Lock()
def echo(s):
time.sleep(1e-3*random.random()) # instead of threading.Timer()
with lock:
print s
for c in 'abc':
threading.Thread(target=echo, args=(c,)).start()
# Run until empty line is found:
$ while ! python example.py 2>&1|tee out|grep '^$';do echo -n .;done;cat out
....................
b
c
a
The output should not contain empty lines, but it does. I understand that print
is not thread-safe, but I would've thought the lock should help.
My machine:
$ python -mplatform
Linux-2.6.38-11-generic-x86_64-with-Ubuntu-11.04-natty
Extra lines are printed on py26, py27, pypy.
py24, py25, py31, py32 behave as expected (no empty lines).
sys.stdout.flush()
after the print
doesn't solve the problem:
with lock:
print(s)
sys.stdout.flush()
even more strange that ordinary sys.stdout.write()
doesn't produce empty lines with lock:
with lock:
sys.stdout.write(s)
sys.stdout.write('\n') #NOTE: no .flush()
print
function works as expected (no empty lines).
$ tox
The condition occurs when one thread tries to modify a shared resource at the same time that another thread is modifying that resource – this leads to garbled output, which is why threads need to be synchronized. The threading module of Python includes locks as a synchronization tool.
Generally, Python only uses one thread to execute the set of written statements. This means that in python only one thread will be executed at a time.
Only a single thread can acquire that lock at a time, which means the interpreter ultimately runs the instructions serially. This design makes memory management thread-safe, but as a consequence, it can't utilize multiple CPU cores at all.
To print on the same line in Python, add a second argument, end=' ', to the print() function call.
Take a look at this stackoverflow thread: How do I get a thread safe print in Python 2.6?. Apparently, printing to sout is not thread-safe.
If you turn on verbose threading, you can see this better:
threading.Thread(target=echo, args=(c,), verbose=True).start()
I get output like this:
MainThread: <Thread(Thread-1, initial)>.start(): starting thread
Thread-1: <Thread(Thread-1, started 6204)>.__bootstrap(): thread started
MainThread: <Thread(Thread-2, initial)>.start(): starting thread
Thread-2: <Thread(Thread-2, started 3752)>.__bootstrap(): thread started
MainThread: <Thread(Thread-3, initial)>.start(): starting thread
Thread-3: <Thread(Thread-3, started 4412)>.__bootstrap(): thread started
MainThread: <Thread(Thread-2, started 3752)>.join(): waiting until thread stops
a
b
Thread-1: <Thread(Thread-1, started 6204)>.__bootstrap(): normal return
Thread-2: <Thread(Thread-2, started 3752)>.__bootstrap(): normal return
MainThread: <Thread(Thread-2, stopped 3752)>.join(): thread stopped
MainThread: <Thread(Thread-3, started 4412)>.join(): waiting until thread stops
Thread-3: <Thread(Thread-3, started 4412)>.__bootstrap(): normal return
MainThread: <Thread(Thread-3, stopped 4412)>.join(): thread stopped
c
You can see that thread 3 is shown as finishing before printing the 'c' character. This clearly cannot be the case, so this leads me to assume that printing to the console is not thread-safe.
This, however, does not explain why printing to sys.stderr appears to work correctly.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With