[Tutor] running multiple concurrent processes

[Dave Angel]

On 10/30/2012 05:10 PM, richard kappler wrote:
> Oscar, thanks for the link, though I must say with all due respect, if it
> was "obvious" I wouldn't have had to ask the question. Good link though. I
> suspect the reason I didn't find it is I did my searches under threading as
> opposed to multi-processing.
> 
> Dave, no offense taken, great write-up. Now I understand more, but am quite
> possible even more confused, but will take what you wrote to guide me
> through further research. This is enough to get me started though. I'm
> thinking multi-threading might be the way to go, but I want to re-read the
> docs on multi-processing. Our internet went out for a while so I was
> reading that on my phone, want to read again on a big screen.
> 
> For the record, I'm running Ubuntu Linux 12.04 (not quite a noob anymore,
> been on Ubuntu since Maverick, pretty handy with the shell) on an HP G62
> which has a 2.5GHz dual core Turion II (upgraded to 8 gig memory if that
> matters, I'm thinking it doesn't).
> 
> I'm also going to investigate running it as a monolithic program instead of
> several smaller ones running concurrently as suggested by another poster.
> Frankly I don't think that would work as well, and it would involve a great
> many loops that might erroneously end up nigh-continuous, so I see danger
> there, but will investigate.
> 
> I was at one point actually thinking of setting things up on Timer from the
> threading module, so that parameters would update either event driven (ex:
> a sensor crossing a threshold) or time driven (ex: poll sensors every 30
> seconds). That seems doable, but poor form to me. Rather I should say that
> seems a low level way out that is attractive only due to my fairly low
> level of Python knowledge at this point. Either threading or
> multi-processing seems both more elegant and more efficient.
> 

I have no experience with PySerial, but if you can block waiting for the
next "message," then that's a simple place to make a separate thread.
And it beats using 30 second timers.  A robot can move quite a ways in
30 seconds, before you realize that 20 seconds ago it was headed off the
edge of something.


> Might you explain a little more in depth on the pitfalls of threading, and
> also the event loop you mentioned, or point me towards some resources? As I
> mentioned earlier, I did read the threading docs, was pretty lost. I'm no
> idiot, but I'm a public school math teacher trying learn this stuff to help
> engage my students, not a degreed computer science major or full time
> programmer.
> 

The real problem with threading is simply that any mutable static
variable should not be shared, except maybe rarely when there's at most
one thread that updates it, and the others just read it.  Those can
still be a problem if they're containers, as one thread could be
iterating over it while another changes it.

In Python they're not called static, but the ones I mean are typically
top-level (or module) variables, and class attributes.  When the thread
starts, you have a thread-object, and you can safely read and write
attributes stored there, because it's pretty easy to know that they're
unique to your own thread.  Similarly, it's safe to use local variables
within a function, and of course instance attributes of a class,
providing the instance is not shared.

Anyway, the trick is that when threads DO need to share modified data,
you want to use a library you can trust, such as Queue.  If you use
other mechanisms, they need to be either VERY simple, or designed by
someone experienced.


The pitfall for multithreading is that sometimes you use a shared
variable without even realizing it.


-- 

DaveA