|Home About Us Services Clients Resources Blog Careers Orderbox™||contact us Site map links|
About Multithreading - Pros and Cons
Multicore CPUs have been mainstream for sometime and the majority of notebooks and desktop machines that people purchase nowadays will have them inside. Thus, it is more important than ever for competent programmers to know how to take advantage of multithreading in their programs, or at least understand how threads work.
Threads are just one of the many abstractions that can take advantage of multiple execution units in the hardware. They are pretty low level and map pretty closely to how the hardware works. As such, they are in fact very tricky to use and debugging programs that use them require a degree of forethought and analysis on a completely different order from ordinary sequential programming. The following links are but two small samplings of comments on the issue and are provided for the reader to appreciate just how cautious one should be when considering the use of multithreading.
Even for 'experts', threads are fiendishly difficult to work with, despite their deceptive initial simplicity. I have had occasion to use threads in simple ways a few times in my programming career and while I thankfully have not gone through the sort of thread hell I've heard described, I could easily imagine situations where even the simple uses I have made of threading would have led to such. I chalk up the preservation of my virginity to being adequately forewarned and therefore curbing a great deal of ambitiousness in my use of threads.
In those instances where I chose to use threads, I did so because I felt that making the code multithreaded would lead to considerably simpler code structure (e.g. much fewer lines) than if I hadn't. The caveat was that if I wasn't careful, all the time I save making the code shorter and faster to read wouldn't make up for the time consumed figuring out where my code went wrong in the case of a horrible deadlock. My first use of threads was many years ago in Delphi to control a bill acceptor and after that a couple of times more in Python for network code. So far I have not encountered debugging nightmares and it seems to have been worth it to use multithreading.
For code tasks that can be very obviously distributed over multiple cpus/cores, you will definitely want to consider the use of multithreading. While anti-threaders will propose the use of many other alternative mechanisms - which you should definitely consider - the fact that all modern OSes support threads directly means that they are the most universally supported form of concurrency mechanism available. Thus you can reasonably expect a mature implementation to be present on just about any environment you may need to port your code to.
For people who intend to use multithreading to get the big speed gains promised by multicore machines, the big caveat is that under CPython, using threads will be useless for this purpose (see GIL). A similar limitation also applies for Ruby. Happily however, the GIL is not present under Ironpython nor Jython and so, running your multithreaded Python code under them WILL give you the expected performance benefits (see this post). Such instances of being able to have your cake and eat it too is one of the many reasons Python brings so much joy to its users.
How to use Threads in Python
Compare to other programming languages, the sample code to demonstrate how to use threads in Python is truly simple:
from sys import stdout from time import sleep from random import randint from thread import start_new_thread def worker(name): wait=randint(2,7) sleep(wait) print "I'm",name,"and waited",wait,"seconds." stdout.flush() start_new_thread(worker,("thread 1",)) start_new_thread(worker,("thread 2",)) start_new_thread(worker,("thread 3",)) while True: pass
The above shows how to spawn threads using the older
Web Development / Rich Internet Applications (RIA) Development
|© 2003-2019 Neotitans Technologies Inc.||contact/hire us|