[kwlug disc.] how long would it take you to learn threads programming?

[Andrew Kohlsmith (lists)]

On April 22, 2008 10:12:12 am Robert P. J. Day wrote:
>   i've been asked about the possibility of teaching a course in
> pthreads programming in linux and, since i already have some material
> lying around on the topic, i'm at least going to put together a
> proposal for such a course.  the question is -- how long should such a
> course take?

You could have the basics done in under a day, but the real devil is not in 
the pthreads API or even in understand the concept of a bunch of "processes" 
running around in the same memory space (which always reminds me of "ein 
volk, ein Reich, ein Führer"), it's in the devilish details of multithreaded 
programming.

>   anyone here have an opinion?  anyone ever take such a course?
> anyone who's an accomplished threads programmer have an idea of what
> *they* would consider an appropriate time frame?  i mean, i have no
> objection to getting paid for 3 or 4 days of training, but not if i
> have to fill a lot of that time with empty space just to drag it out.

I guess it all comes down to your target audience; if they're competent 
programmers, you could probably hit 3 days because you'd spend two of them on 
scheduling options, concurrent access (locking and lockless), priority 
inversion and things that trip up even experienced programmers once you throw 
the multiple execution wrench into the machine.  You could come up with a 
bunch of examples to run through and let THEM hit the obvious bugs and work 
through them as a group instead of just telling them about the pitfalls... 
There are a lot of opportunities for "eureka!" moments in this kind of a 
course.

If your target audience is low to mid-level programmers I wouldn't even try to 
tackle this; "real" multithreaded programming is not a beginner or even 
intermediate topic.  They need to have a solid grasp on regular old IPC 
before hitting anything even moderately threaded.  Just IMO, though.  I have 
been programming in C for close to 15 years now, and "just using threads" was 
easy, trivial even.  However, getting a solid grasp on the scheduling options 
and effects of priority and yielding took some real work, and debugging some 
of this stuff was downright maddening. I certainly consider being able to do 
anything non-trivial in a multithreaded fashion to be an advanced-level task.

Now I had another strike against me; I was doing this all on m68knommu, so in 
addition to trying to debug threads, I was fighting a total lack of memory 
protection and also gdbserver, which is pretty much incapable of debugging 
multithreaded applications on that platform.  I ended up porting the app to 
x86, writing a couple device drivers and debugging most of it there. The 
application was better off because the exercise increased its portability and 
exposed a few places I was making assumptions about byte order, and the 
overall experience gained was priceless.

What I first thought I knew about multithreaded programming turned out to be a 
lot less than what was was needed to *really* do multithreaded programming.  
I liken it to knowing how an engine works vs. actually tearing one down to 
solve a problem.  :-)

Which reminds me of my all-time favourite adage:

The difference between theory and practise is that in theory, there is no 
difference between theory and practise.

-A.