I'm currently working on a project that gets social network notification data from Facebook, Twitter and GMail. When a notification is received, a serial signal is sent to an Arduino UNO, which flashes an LED that corresponds to that social network.

For optimal speed, I have decided to use multithreading, through the threading module. What I would like to know is whether or not I need to use threading.Lock() and create a lock. Over IRC, KermM gave me some advice:



The code is seperated into a series of classes. SocialLights governs the serial connection to the Arduino.


Code:


Thus far, I have written two social network monitoring classes, one for GMail and the other for Twitter. They both follow this sort of format.


Code:


I have heavily condensed this code, but it looks roughly like this.

In the main body of code, each class is instantiated, and is attached to a SocialLights object which is also instantiated.


Code:


Should I be using threading.Lock() and using the acquire() and release() methods?

Easy way to ensure you won't cause tricky threading bugs: have no shared state. This is a simple case of a multi-producer single-consumer system, which is well-suited to the builtin Queue class.

Just give each 'Reader' and 'SocialLights' a handle to a Queue, then put() and get() messages as desired. The Queue will ensure you don't cause ugly errors.

---

Performance isn't a very compelling argument for multithreading here, since you'll be spending the majority of the time waiting for I/O in this application. More compelling is simplicity, since it's somewhat easier to say "Each source runs independently and pushes messages into the queue for transmission" than it is to interleave all the processing.

It doesn't matter in this case (as noted above, you're spending most of the time just waiting on I/O anyway), but if you need to allow multiple threads to actually execute at the same time you'll need to use multiprocessing due to the tyranny of the GIL.

This also sounds like a good application of an application-specific password for gmail (so you can easily revoke the application's access without mucking with changing your password), but that's just a minor comment.