1个工作线程比4个快？

Question

I am reading myself into multighreading in python and came up with this simple test: (btw. this implementation might be very bad, I just wrote that down quickly for testing purpose. Buf if there is something terribly wrong I would be thankful if you could point that out)

#!/usr/bin/python2.7

import threading
import timeit

lst = range(0, 100000)
lstres = []
lstlock = threading.Lock()
lstreslock = threading.Lock()

def add_five(x):
    return x+5

def worker_thread(args):
    print "started"
    while len(lst) > 0:
        lstlock.acquire()
        try:
            x = lst.pop(0)
        except IndexError:
            lstlock.release()
            return
        lstlock.release()
        x = add_five(x)
        lstreslock.acquire()
        lstres.append(x)
        lstreslock.release()

def test():
    try:
        t1 = threading.Thread(target = worker_thread, args = (1,))
        #t2 = threading.Thread(target = worker_thread, args = (2,))
        #t3 = threading.Thread(target = worker_thread, args = (3,))
        #t4 = threading.Thread(target = worker_thread, args = (4,))
        t1.start();
        #t2.start();
        #t3.start();
        #t4.start();
        t1.join();
        #t2.join();
        #t3.join();
        #t4.join();
    except:
        print "Error"

    print len(lstres)

if __name__ == "__main__":
    t = timeit.Timer(test)
    print t.timeit(2)

Despite the terrible example I see the following: one thread is faster than 4. With one thread I get: 13.46 seconds, and with 4 threads: 25.47 seconds.

Is the access to the list by 4 threads a bottleneck thus causing slower times or did I do something wrong?

Answer 1

In your case, the Global Interpreter Lock isn't actually the problem.

Threading doesn't make things faster by default. In your case, the code is CPU bound. No thread is ever waiting for I/O (which allow another to use the CPU). If you have code which needs 100% of the CPU, then threading will only make it faster if a lot of the code is independent which your's isn't: Most of your code is holding locks, so no other thread can proceed.

Which brings us to the cause of the slowdown: Switching threads and fighting for locks costs time. That's what eats 12s in your case.