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

[Denver Gingerich]

On Tue, Apr 22, 2008 at 10:12 AM, Robert P. J. Day
<rpjday at crashcourse.ca> wrote:
>
>   i'm interested in some feedback from the folks on this list who have
>  some experience with programming in POSIX threads.

I don't have experience with POSIX threads other than seeing the API
once, but I just finished a course on concurrency so I should be able
to offer something to the discussion.

>   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?

The more, the better.  The course I took had 32 hours of class time in
total (24 80-minute classes) with 6 assignments that took 5-10 hours
each.  I consider myself competent with the material, but by no means
an expert.

>   as a template, i was also sent a couple outlines to use as models
>  from other training providers for their courses on threads
>  programming, one which takes 3 days, the other takes 4 days.  but,
>  frankly, i just don't see how i could fill even 3 days with threads
>  programming.
>
>   i'm thinking i can stretch it to 2 days if i add content on
>  debugging threads or anything else that comes to mind but, beyond
>  that, 2 days would seem to be more than sufficient.
>
>   anyone here have an opinion?  anyone ever take such a course?

The course I took was CS343: Concurrent and Parallel Programming at
the University of Waterloo.  The web site is:

http://www.student.cs.uwaterloo.ca/~cs343/

I suggest looking at the course notes at least:

http://www.student.cs.uwaterloo.ca/~cs343/documents/notes.pdf

These are basically the textbook for the course.  The concurrency
actually starts at page 49 of the notes; prior to that we deal with
coroutines and exceptions.  I can point you to specific topics if you
have trouble finding them in the notes.

>  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.

It really comes down to how competent you want your students to be
when they leave and how competent they are when they start.

Unless your students are already familiar with concurrent programming,
you should have no trouble filling 4 days of training with all the
concurrency topics out there.  Covering mutual exclusion,
synchronization, barriers, semaphores, deadlocks, debugging, etc.
should give you plenty to teach for 4 days.


I would suggest teaching something other than pthreads if you can.
While pthreads is somewhat of a standard, it's not a very good one for
a variety of reasons.  It is very low-level; you have to build things
like barriers and semaphores yourself, increasing the chance that
you'll screw it up.  It is not part of the language so the compiler
cannot detect incorrect uses of the API, even if they could
theoretically be detected at compile-time, so you have to do more
runtime debugging.  The functions are not type-safe; for example, you
must pass a void* as an argument to the start function.

pthreads makes the sharp knife of concurrency even sharper by pushing
much of the errors from compile-time to runtime.  Concurrent programs
are already difficult to debug even if the compiler does all the
checks it can.  Unless you know concurrency inside and out, it is very
difficult to use pthreads correctly.  The CS343 course notes discuss
pthreads; see p. 131-133 in section 10.2.


In CS343, we were taught uC++ (micro C++).  uC++ implements pretty
much every concurrency feature you could want, including barriers,
semaphores, counting semaphores, and tasks (threads).  It's not as
widely used as pthreads, but there is a Debian package of it and it's
relatively complete.  There are lots of other concurrency libraries
out there, including those in Boost, Java, and C#.  Java threads are
more widely used than uC++, but they have some problems, such as wait
statements needing to be in while loops.  I don't have experience with
any of the other libraries.


Which concurrency library/language you choose depends largely on what
you're trying to teach.  There's a lot you can do with concurrency.
Perhaps you should limit the tutorial to a specific subset of
concurrent applications, such as multi-threading in web servers, web
browsers, or high-performance computing (ie. splitting algorithms into
several threads).

Certainly you should spend a lot of time on getting people to write
concurrent programs and debug them.  Debugging is especially important
as it tends to be the hardest part of concurrent programming.  But be
sure to warn people that even if their program works fine for several
minutes or hours, there's no guarantee it's bug-free.  Errors in
concurrent programs, such as race conditions, can be extremely hard to
find and may not manifest themselves for days or months of continuous
operation.  It is imperative that you understand what your concurrent
program is doing.  It is not sufficient to use a simple compile and
run test on concurrent programs, though this usually works fine on
sequential programs even when you don't understand what the code is
doing.


I echo Andrew Kohlsmith's comments for the most part.  Writing correct
multi-threaded applications is hard and must be approached with great
caution.

Whatever library/language you choose to use, remember that you're not
teaching a library, you're teaching a whole new programming paradigm.
Teaching concurrent and parallel programing is kind of like teaching a
sequential programmer how to write functional programs.

Denver