Subject: Re: [linux-audio-dev] Article about multithreading
From: Paul Davis (pbd_AT_Op.Net)
Date: Sun Jun 17 2001 - 15:44:16 EEST
>I was wondering: aren't there any toolkits 'out there' to simplify
>writing multithreaded apps? (providing monitors for synchronisation
>etc.) It would be difficult to design such a toolkit though as most
>of the code is very application specific, with maybe the exception
>of locks / monitors for concurrency / deadlock avoidance ?
there are lots. or at least several. the problem with many of the
tools that provide "higher levels" of functionality than that
presented by pthreads is that they degrade performance. people have
been writing parallel programming toolkits for at least 10 or 15 years
now, perhaps even 20. AFAIK, no single toolkit has ever risen to
prominence except for pthreads and the windows thread API, which
hardly even qualify as the sort of thing you're ralking about.
deadlock avoidance is an bit of an illusory goal. there has been some
mostly theoretical work on such things, but once again, you lose
performance (a lot, if you use mutexes a lot), and in general, a
pathological situation can still cause deadlocks that were not found
by an analytical stage.
<my-two-cents>
serial programs are very similar, conceptually, to things we do
everyday. the most obvious examples: following a cooking recipe,
following travel directions. but writing parallel programs is hard. as
humans, we never consciously do anything in parallel. we might
"multitask", but its on a UP system, not an MP system. it doesn't
suprise me that we, as humans, find writing such software to be a
difficult task. i don't believe that it can ever get particularly
easy, because it requires us to think about things in metaphors and
analogies that don't map to anything in our conscious experience.
interestingly, the best qualified may be those used to organizing
groups of people around a single task, rather than those who actually
*do* such tasks. managers have to frequently resort to things like
"while susan is doing X, and steve is doing Y, oh wait, steve can't
complete Y until susan is finished with X ...". while that's going on,
neither steve nor susan have any "parallel" experience. needless to
say, most programmers (not all, just most) are the steve's and susan's
of the world. OTOH, there is demonstrable evidence that very few
managers are good at this either, so there may be no hope :)
</my-two-cents>
--p
This archive was generated by hypermail 2b28 : Sun Jun 17 2001 - 15:42:53 EEST