[ACCEPTED]-threading appears to run threads sequentially-multithreading

Currently in python, threads get changed 11 after executing some specified amount of 10 bytecode instructions. They don't run at 9 the same time. You will only have threads 8 executing in parallel when one of them calls 7 some I/O-intensive or not python-affecting 6 module that can release GIL (global interpreter 5 lock).

I'm pretty sure you will get the output 4 mixed up if you bump the number of loops 3 to something like 10000. Remember that simply 2 spawning the second thread also takes "a 1 lot" of time.

In the time it takes the second thread to 8 start the first thread loops and prints 7 already.

Here it looks like this, you can 6 see the 2nd thread starting after the first 5 emitted a few hellos.

Hello
Hello
Hello
Hello
Hello
Helloworld

Helloworld

Helloworld

Helloworld

Helloworld

world
world
world
world
world

Btw: Your example is 4 not meaningful at all. The only reason for 3 Threads is IO, and IO is slow. When you 2 add some sleeping to simulate IO it should 1 work as expected:

import threading
from time import sleep

def something():
    for i in xrange(10):
        sleep(0.01)
        print "Hello"

def my_thing():
    for i in xrange(10):
        sleep(0.01)
        print "world"

threading.Thread(target=something).start()
threading.Thread(target=my_thing).start()

a wild mix appears:

worldHello

Helloworld

Helloworld

worldHello

Helloworld

Helloworld

worldHello

Helloworld

worldHello

Helloworld

The behaviour may also change depending 19 on if the system is using has a single processor 18 or multiple processors, as explained by 17 this talk by David Beazley.

As viraptor says, the 16 first thread will release the GIL after 15 executing sys.getcheckinterval() bytecodes 14 (100 by default). To crudly summarise what 13 David Beazley says, on a single processor 12 system the second thread will then have 11 a chance to take over. However on a multi-core 10 system the second thread may be running 9 on a different core, and the first thread 8 will try to reacquire the lock and will 7 probably succeed since the OS will not have 6 had time to switch processors. This means 5 that on a multi-core system with a CPU-bound 4 thread the other threads may never get a 3 look in.

The way round this is to add a sleep 2 statement to both of the loops so that they 1 are no longer CPU bound.

This really depends on your Operating System's 5 scheduler, your processor.
Other than that, it 4 is known that CPython's threads aren't perfect 3 because of the GIL(PDF), which, in short, means 2 that a lot of the times threads do run sequentially, or 1 something of that sort.

Generally, the secret is to always ensure 4 when you are starting the threads you use 3 the below syntax.

Note threading.Thread(target=threadSet1).start() the function threadSet1 has not brackets at the end.

import threading
from time import sleep

def spawn(num, typex):
    import time
    start = time.time()
    print(num, typex)

def threadSet1():
    for i in range(1000):
        sleep(0.01)
        t = threading.Thread(target=spawn(i, "world"))
    t.daemon = True
    t.start()
def threadSet2():
    for i in range(1000):
        sleep(0.01)
        t = threading.Thread(target=spawn(i, "hello"))
        t.daemon = True
        t.start()
if __name__ == '__main__':
    threading.Thread(target=threadSet1).start()
    threading.Thread(target=threadSet2).start()

Do not fall into the trap 2 of using the below syntax as it will execute 1 them serially Note the functions have brackets at the end. threading.Thread(target=threadSet1()).start() threading.Thread(target=threadSet2()).start()