They will be executed simultaneously, but not in parallel. The OS will often switch between the two threads so that they can do their job. This is what is meant by "simultaneous"; one thread does not need to wait for another thread to finish before it can start working. But because of the GIL, they will never work at the same time when each of them runs on the other core in parallel. Each thread starts a bit, pauses while another thread is running, then starts again, then pauses, etc.
It is simple enough to make sure that you simply run your sample code. Here is the output on my machine:
hello hi hello hi hello hi hello hi hello hi hello hi hello hi hello hi hello hi
It is clear that both threads are running. Each thread is slower than if only one thread was running in the program.
Consider this example where each thread computes a Fibonacci sequence:
import thread import time def fib(n): if n <= 1: return n return fib(n-1) + fib(n-2) def test(): while True: start = time.time() out = fib(32) print "hello %s: %s" % (out, str(time.time() - start)) def test2(): while True: out = fib(20) def start_thread(): try: thread.start_new_thread( test2,() ) except: print "Error: Unable to start thread"
Only when running test (so there is no second thread) do I get this output:
hello 2178309: 0.953778982162 hello 2178309: 0.954975128174 hello 2178309: 0.95578789711 hello 2178309: 0.949182033539
If I run test2 in the background, I get the following:
hello 2178309: 4.07990288734 hello 2178309: 4.08523893356 hello 2178309: 2.51651597023 hello 2178309: 2.13291287422 hello 2178309: 2.19885015488
As you can see, performance is a huge success.
Please note that if one of the threads does something that gives the GIL blocking I / O, or is called into the C library that issues the GIL, you will not see such a performance degradation, because in this case both threads can actually work in parallel. This does not apply in the above example, since no thread does the work that issues the GIL.