Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer,comp.lang.c++ Subject: Re: What's the deal with deadlocks Date: Tue, 19 Apr 2011 23:01:48 -0400 Organization: albasani.net Lines: 60 Message-ID: References: <23020668-d86c-489a-988b-7b379f34851c@j13g2000pro.googlegroups.com> <575d7b43-51c4-4905-ba16-15fe9b78373e@t16g2000vbi.googlegroups.com> <913q7eFpdlU3@mid.individual.net> <7c038630-5773-4ef1-8b59-1a0d6fa9acd5@z7g2000prh.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.albasani.net pkOEda/lVuVaJ32ICFzZ2yLv85u/6+kXlyLPWY9FBtJ6jFIFN0xHiKZws4G9DmcoZTQFM/lJizROOG64SYH4jVeW3edYl2jco8zLBW/GKjKILqYY00v2N9Oz85LJQSVW NNTP-Posting-Date: Wed, 20 Apr 2011 03:01:48 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="J4u4yFfknqlvW6okuCx0dr8KbSVFcV8tRdyZdylvdbuFUBCq8Bwi/bIjhMowh017NgrpCjk9eCysEbVmXR11WbsgtX1CFbgIVV+XHorlk5BrkRcZWmCrnDvfZDNmgAQl"; mail-complaints-to="abuse@albasani.net" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 In-Reply-To: <7c038630-5773-4ef1-8b59-1a0d6fa9acd5@z7g2000prh.googlegroups.com> Cancel-Lock: sha1:X0awQ76u0ZJ84AdQFAAJ4Z/Idos= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:3154 comp.lang.c++:4045 Joe Snodgrass wrote: > Ok, so tell me if this is how it works. I'm going to respond to your /reductio ad absurdum/ as though you were presenting a serious argument. > You got a concurrent programming project, let's say in C++, and you're > climbing the walls, because the results are unpredictable, the > debugger shows nothing and the code looks fine. The argument breaks down right here. The code *looks* fine is a function of how one looks, not of the code. Buying OCCAM or MAGICBOOJUM won't fix diddly, because the failure is in the Mark 1 Eyeball and associated neural control and analysis circuits, not the software tools. "The debugger shows nothing" is useless because debuggers don't diagnose concurrency issues until they happen, and then only if you catch them in the right place. But hey, you throw enough shit at the wall and some of it will stick, right? "The results are unpredictable" only because one hasn't gathered enough information to make a prediction. The problem isn't in the results, once again. The failure is in the one gathering the information. So given the failure in the premises, any correctness in the conclusion will be pure coincidence. > You say to yourself "It's gotta be a race condition, right? I mean > I've tried everything else, and the behavior is consistent with that." Right, because incomplete information gathering combined with lame and ridiculously insufficient and misguided analysis should always be followed immediately by an baseless leap to an unfounded conclusion, followed by a rush to a randomly-chosen and utterly misunderstood ameliorative strategy. > The solution is to push C++ onto the back burner, whip out your credit > card and buy a copy of Occam (or Linda, or whatever the kids are using > these days.) > > Your job now becomes to interface Occam into your existing C++ code > and use the Occam features to find and fix the race condition. Then > you go back to C++ and work on whatever the boss says he wants done > next. > > But the key is to give up all hope of ever fixing the race condition > WITHOUT a language like Occam, because if you don't buy Occam, you're > gonna be twisting in the wind until you're so far behind schedule that > the boss fires you. > > Am I correct that my description is a highly reliable portrayal of how > these situations develop? No. At least, there's no evidence here that you are. -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg