I haven't read the reference yet - I ought to, but I felt inclined to share my gut feeling first.
writing multithreaded code tripled software costs
A factor of three, eh? as little as that?!
I write primarily as a Java developer and I guess it comes down to the skills of individual colleagues. Some seem totally at ease with complex dynamic behaviour and rise to the challenge of Futures and Executors and the like. But I think most just "have a go", blithely ignorant of uncaring of the serious issues involved. This leads to testing difficulties, ongoing cost and risk piling up.
I sometimes feel this myself whenever I'm tempted to let loose another 'synchronized' into the wild. I inevitably find myself a few weeks later, machete in hand, hiking back out into 'the wild' to attempt to re-tame those lost 'sychronizeds'. I'd rather do a clean JCSP-like design but, usually, there is no other choice because of the constraints of some pre-requisite framework or product we're working with.
Fundamentally, we start from the wrong place for it to be as easy as it ought to be. This is deeply ingrained into our mainstream technology.
I'm not glum about this - aside from perversely enjoying the challenges, I always look forward to the next 'ahah!' conversation with a colleague who's just realised where we're at and what might be possible if our starting point were slightly different.
Rick :) -- Big Bee Consultants Limited : Registered in England & Wales No. 6397941 Registered Office: 71 The Hundred, Romsey, Hampshire, SO51 8BZ