On 28 Mar, 15:52, [EMAIL PROTECTED] wrote: > I'm having trouble explaining the benefits and tradeoffs of threads to my > coworkers and countering their misconceptions about Python's threading model > and facilities.
Python's threading module is modelled on Java's thread model. There are some minor differences, though. Whereas Python has special lock objects, Java can lock (synchronize) on any object. > They all come from C++ and are used to thinking of > multithreading as a way to harness multiple CPU cores for compute-bound > processing. I also encountered, "Python doesn't really do threads" today. > *sigh* You can't use threads for that in CPython, due to the GIL (global interpreter lock). The GIL resembles the BKL in earlier versions of the Linux kernel. Due to the GIL, multiple threads cannot be simultaneously in the Python interpreter. This e.g. means that I cannot implement a parallel QuickSort in pure Python and get performance gain from multiple CPUs. Although common misbeliefs, this DOES NOT mean: * Python threads are not useful. * Python programs cannot utilize multiple CPUs or multi-core CPUs. Here is the explanations: The GIL can be released by extension modules, which are native libraries of compiled C, C++ or Fortran. This is the key to the usefulness of Python threads. For example: * Python file and socket objects are extension modules that release the GIL. The GIL is released when a thread is waiting for i/o to complete. This e.g. allows you to write multi-threaded server apps in Python. * NumPy is an extension library that releases the GIL before commencing on a time-consuming CPU-bound computations. If you have N CPUs, NumPy allows you to do N FFTs or SVDs in parallel. * ctypes is an extension module that allows Python code to call DLLs. ctypes releases the GIL before the foregin call on cdecl functions (but not stdcall functions!), allowing you to call many cdecl DLL functions in parallel. * Extension libraries that spawns multiple threads will utilize mutiple CPUs, even if the GIL are not released. There is also other reasons why threads are useful, that does not depend on extension modules releasing the GIL. One example: Multithreading is the key to responsive user interfaces, as only one thread should process events. An event-handler should spawn a thread before commencing on a time-consuming task. IronPython and Jython are implemented without a GIL. (They run on the .NET and Java VMs, respectively.) Finally, remeber that pure Python often runs 200 times slower than pure C on algoritmic code! If you need to do lengthy computational tasks, a pure Python may not be what you want. With two dual-core CPUs, nearly perfect load scheduling, a no-GIL implementation of Python, a pure Python would still be more than 50 times solwer than a single-threaded C solution. Hence, you would gain a lot more from profiling, identifying the worst bottlenecks, and translating those parts to C. -- http://mail.python.org/mailman/listinfo/python-list
