ok, "too well" obviously is a wrong wording, good catch. I meant "too
well intended." In linear programming, it normally doesn't hurt to add
a little extra code here and there (even when it's not good style),
but in concurrent programming an example for "not good enough" is "not
syncronized well enough" whereas an example for "too well intended" is
oversyncronized which may end up in deadlocks, convoy effects, factual
coroutines or other things that not only annihilate the advantages of
concurrent programming but frequently make the runtime behavior worse
and harder to maintain than without concurrency at all.
a typical attitude you'll frequently find in people who don't do it
well enough is "ok, there is some concurrency problem, so I'll play
with a delay here and a timeout there until it appears to work." A
typical attitude you'll frequently find in people who do it too well
intended is "ok, there is some concurrency problem, so I'll add a
semaphore here and a critical section there" without really analyzing
whether there is conflict potential. The first person will most
probably get into trouble when the problem shows up again in the
field, and the second will get in trouble when his application not
unly doesn't run faster than before he added concurrency but locks up
in the field (frequently only in hard to track fringe conditions such
as full moon).
Quoting Harry Spier <[email protected]>:
On Tue, Jul 3, 2012 at 4:07 PM, Rüdiger Asche <[email protected]> wrote:
keep in mind that concurrent software desing
is one of the outer space limits of computation still - one of the things
that won't work if you don't do it good enough but likewise won't work if
you do it too well.
First thanks for your detailed reply.
I'm not clear what you mean by "won't work if you do it too well".
Thanks,
Harry
____________________
Racket Users list:
http://lists.racket-lang.org/users
