Re: Isn't this in favour of Ada??

["Marc A. Criley" <mcNOSPAM@mckae.com>]

Jeffrey Carter wrote:

> Even when Ada is used for concurrent systems, Ada's concurrency features 
> are often not used. While technical reasons are often given for such 
> decisions, they rarely are true. Generally, the real reasons are the 
> designers' lack of understanding of concurrency, replacing it with 
> something more familiar.

Unfortunately I've found this to be all too true :-(  I've been involved 
with fixing up more than one system (long after the original designers 
have moved on) that had horrendous misuse of tasking.

One had tasks handling the buffering of data in and out of sockets.  A 
reasonable application of tasking, yes?

Except all the interaction between the tasks and the application 
occurred _within_ the 'accept' blocks.  Meaning a message would come on 
the socket and into the socket-monitoring task, rendezvous and block on 
the buffering task, which would rendezvous and block on the message 
processing task, which would generate output that would rendezvous and 
block on the output buffering task, which would rendezvous and block on 
the output socket transmission task, which then write out the message, 
followed by unblock, unblock, unblock, etc.  I am not making this up.

I characterized this as the world's most expensive procedure call chain.

-- Marc A. Criley
-- www.mckae.com
-- DTraq - XPath In Ada - XML EZ Out