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

[R. Brent Clements]

I remember I spent about a week or so studying the theory of
concurrent processing, covering both multithreaded and and large scale
parallel.  The practical was a single afternoon lab exercise.

Brent

On Tue, Apr 22, 2008 at 11:01 AM, Andrew Kohlsmith (lists)
<aklists at mixdown.ca> wrote:
> 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.
>
>
> _______________________________________________
>  KWLUG-Disc mailing list
>  KWLUG-Disc at kwlug.org
>  http://listserv.kwlug.org/mailman/listinfo/kwlug-disc
>