[racket] Racket and concurrency

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 <vasishtha.spier at gmail.com>:

> On Tue, Jul 3, 2012 at 4:07 PM, Rüdiger Asche <rac at ruediger-asche.de> 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
>
>