Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > What's the deal with deadlocks

Reply
Thread Tools

What's the deal with deadlocks

 
 
Ian Collins
Guest
Posts: n/a
 
      04-18-2011
On 04/19/11 08:32 AM, Alf P. Steinbach /Usenet wrote:
> * Lew, on 18.04.2011 22:22:
>> Joe Snodgrass wrote:
>>> Here's how NASA handles race conditions.
>>>
>>> http://tinyurl.com/42p2t5f
>>>
>>> I searched Dr. Dobbs J, and got ten pages of matches.

>>
>> That link was worth ten times the expected maximum value for a Usenet link.
>>
>> Not least because it led to http://www.usingcsp.com/cspbook.pdf, /Communicating
>> Sequential Processes/, by C. A. R. "Tony" Hoare, with foreword by Edsger W.
>> Dijkstra.

>
> I have that in hardcover.
>
> Some other interesting old books:
>
> Parallell Programming in ANSI Standard ADA - George W. Cherry
> Lucid, the Dataflow Language - William W. Wadge& Edward A. Ashcroft
> OCCAM Programming Manual - INMOS Limited
>
> OCCAM was sort of a language designed to express more or less directly Hoare's
> concepts.


Someone else who has used OCCAM in anger? Wow I thought I was the only
one left!

--
Ian Collins
 
Reply With Quote
 
 
 
 
Alf P. Steinbach /Usenet
Guest
Posts: n/a
 
      04-18-2011
* Ian Collins, on 18.04.2011 23:53:
> On 04/19/11 08:32 AM, Alf P. Steinbach /Usenet wrote:
>> * Lew, on 18.04.2011 22:22:
>>> Joe Snodgrass wrote:
>>>> Here's how NASA handles race conditions.
>>>>
>>>> http://tinyurl.com/42p2t5f
>>>>
>>>> I searched Dr. Dobbs J, and got ten pages of matches.
>>>
>>> That link was worth ten times the expected maximum value for a Usenet link.
>>>
>>> Not least because it led to http://www.usingcsp.com/cspbook.pdf, /Communicating
>>> Sequential Processes/, by C. A. R. "Tony" Hoare, with foreword by Edsger W.
>>> Dijkstra.

>>
>> I have that in hardcover.
>>
>> Some other interesting old books:
>>
>> Parallell Programming in ANSI Standard ADA - George W. Cherry
>> Lucid, the Dataflow Language - William W. Wadge& Edward A. Ashcroft
>> OCCAM Programming Manual - INMOS Limited
>>
>> OCCAM was sort of a language designed to express more or less directly Hoare's
>> concepts.

>
> Someone else who has used OCCAM in anger? Wow I thought I was the only one left!


You may well be the last: I never used it, I just wanted to learn about it
(within my economic means, and I think I got that manual at a "basement bargain"
shop).

Anyway, this is fun.

Discussing OCCAM, cross-posted to [comp.lang.c++] and
[comp.lang.java.programmer].


Cheers,

- Alf

--
blog at <url: http://alfps.wordpress.com>
 
Reply With Quote
 
 
 
 
Tom Anderson
Guest
Posts: n/a
 
      04-18-2011
On Mon, 18 Apr 2011, Lew wrote:

> Joe Snodgrass wrote:
>> Here's how NASA handles race conditions.
>>
>> http://tinyurl.com/42p2t5f
>>
>> I searched Dr. Dobbs J, and got ten pages of matches.

>
> That link was worth ten times the expected maximum value for a Usenet link.
>
> Not least because it led to http://www.usingcsp.com/cspbook.pdf,
> /Communicating Sequential Processes/, by C. A. R. "Tony" Hoare, with foreword
> by Edsger W. Dijkstra.


If you like Dijkstra - and really, who doesn't - you might enjoy dipping
into the archive of his papers:

http://www.cs.utexas.edu/users/EWD/

There's some heavily obscure stuff in there, but also dry wit, rigorous
thinking, and interesting ideas.

tom

--
A playwright is not the best person to talk about his own work for
the simple reason that he is often unaware of what he has written. --
Alan Bennett
 
Reply With Quote
 
Noah Roberts
Guest
Posts: n/a
 
      04-18-2011
On 2011-04-17 09:15, Joe Snodgrass wrote:
>
> The general concept is simple enough, but it seems to me that you'll
> need special tools to diagnose this specific problem. How do you get
> the debugger to look inside threads, see that they're hung, and find
> out where the problem is happening? Do the debuggers have some
> features that I haven't heard of? TIA.


I myself have always wondered how they could stand the smell.

It's GOT to itch like a mother too.

--
http://crazycpp.wordpress.com
 
Reply With Quote
 
Joe Snodgrass
Guest
Posts: n/a
 
      04-19-2011
On Apr 18, 5:53*pm, Ian Collins <(E-Mail Removed)> wrote:
> On 04/19/11 08:32 AM, Alf P. Steinbach /Usenet wrote:
>
>
>
> > * Lew, on 18.04.2011 22:22:
> >>JoeSnodgrasswrote:
> >>> Here's how NASA handles race conditions.

>
> >>>http://tinyurl.com/42p2t5f

>
> >>> I searched Dr. Dobbs J, and got ten pages of matches.

>
> >> That link was worth ten times the expected maximum value for a Usenet link.

>
> >> Not least because it led tohttp://www.usingcsp.com/cspbook.pdf, /Communicating
> >> Sequential Processes/, by C. A. R. "Tony" Hoare, with foreword by Edsger W.
> >> Dijkstra.

>
> > I have that in hardcover.

>
> > Some other interesting old books:

>
> > * * Parallell Programming in ANSI Standard ADA *- George W. Cherry
> > * * Lucid, the Dataflow Language - William W. Wadge& *Edward A. Ashcroft
> > * * OCCAM Programming Manual - INMOS Limited

>
> > OCCAM was sort of a language designed to express more or less directly Hoare's
> > concepts.

>
> Someone else who has used OCCAM in anger? *Wow I thought I was the only
> one left!


Ok, so tell me if this is how it works.

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.

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."

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?
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      04-20-2011
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 **** 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/wikipedi.../c/cf/Friz.jpg
 
Reply With Quote
 
Joe Snodgrass
Guest
Posts: n/a
 
      04-21-2011
On Apr 19, 11:01*pm, Lew <(E-Mail Removed)> wrote:
> 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 Mark1
> 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 **** at the wall and some of itwill
> 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 arush
> 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.


OK, so two of you have just contradicted me sarcastically, which means
my post must have been wrong. In other words, there ARE ways to find
and fix race conditions with without using a language like Occam.
What are they, and where can I read up on them?
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      04-21-2011
Joe Snodgrass wrote:
> OK, so two of you have just contradicted me sarcastically, which means
> my post must have been wrong. In other words, there ARE ways to find
> and fix race conditions with without using a language like Occam.
> What are they, and where can I read up on them?


Sarcasm for sarcasm - if you set it up, don't be too astonished to receive it
back.

But the points you raised, as ours, were valid and useful if one is trained to
educe the point from Socratic discourse. I interpreted your post as a rather
brilliant diatribe against the same sort of rush to judgment I attacked in my
response, thus I believe us to be allies in championing an intelligent
approach. That is why I introduced my post, "I'm going to respond to your
/reductio ad absurdum/ as though you were presenting a serious argument." I
feel quite sure you were pointing out exactly the sort of flawed reasoning I
attacked in detail. Thus, you are providing the script for the young student,
naively thinking Occam will save the day, and I the for the crotchety teacher
attempting to impose a more engineering-oriented outlook.

That said, the universe of discourse admits of a lot of room besides "Occam is
our savior!" and "you can fix everything without Occam". I don't agree to
frame the discussion in the terms you propose because the world is not limited
to just the options you suggest. You asserted a conclusion that "there ARE
[sic] ways" based on the sole premise (and fact) that Occam is not a magic
bullet, without showing evidence or a chain of reasoning to link those
statements.

In fact, there ARE ways to find and fix race conditions, some with and some
without Occam; they comprise a whole mess of practices and approaches and
mindsets that are and likely always will be active topics of research and
discussion among partisans.

I shall forebear suggesting

http://lmgtfy.com/?q=Java+race+condi...etect+and+cure,

choosing instead to follow that link myself and come up with dozens of useful
leads that I read with pleasure.

I shall not forebear suggesting:

http://java.sun.com/docs/books/effective/
http://www.javaconcurrencyinpractice.com/

nor to scan through many of:
http://www.ibm.com/search/csass/sear...&Search=Search

Also, a scan upthread in this very discussion yields several answers to that
very question. I commend to your attention in particular Dr. Patricia
Shanahan's responses, which in a few short sentences lay the groundwork for
everything you need to know. In one post, she recommends preventing the bugs,
which is actually attainable by disciplined practice and thoughtful design.
In the other, she limns the essentials of troubleshooting such matters.

Your question is excellent, and seminal to the art of programming. If I may
rephrase:

How can one find, fix [and I'll add, prevent] race conditions, deadlocks, and
other such parallel-execution foobars?

Indeed, Grasshopper. Indeed.

--
Lew
His barn burned down, and now he can see the moon.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
What's the deal with deadlocks Joe Snodgrass Java 16 04-21-2011 04:29 AM
deadlocks ndxp@hotmail.com Java 31 12-22-2005 04:42 PM
Deadlocks Mike Carr ASP .Net 9 07-23-2004 07:31 PM
Automatically detecting deadlocks? Rogan Dawes Java 2 05-06-2004 06:27 AM
ASP.NET Deadlocks Martin Blackstone [MVP - Exchange] ASP .Net 6 08-24-2003 02:56 AM



Advertisments