• (nodebb)

    The real problem, though, is that we suspect we're in a deadlock situation.

    A bold assumption that the name has any relation to what throws the exception.

  • (nodebb)

    The real problem, though, is that we suspect we're in a deadlock situation.

    No. The real problem is that they don't know one way or another whether they're in a deadlock situation, and yet they paid an HPC to come in and try to solve deadlock problems. OK, I agree, there were other problems that they knew (really? or did they just suspect, like here?) were deadlock problems, but linking this "suspect" to the rest by talking about deadlocks is ... suspect. (Not sorry.)

    so they brought in a highly paid consultant to try and fix them

    No. They brought in an HPC to try to fix them. Clearly it's not "try and fix" because the HPC didn't fix all of them, and it appears that some ended up worse than before.

  • (nodebb)

    try to fix them

    Ah, one of my pettest peeves. Thank you, sir.

  • Greg (unregistered)

    One would think a highly paid consultant would now better than to catch the exception by value...

  • (nodebb)

    One would think someone posting to such a pedantic forum would know better than to submit without proofreading.

  • (nodebb) in reply to dpm

    Why the F isn't there a "Like" button on this comment board?

  • (nodebb) in reply to dpm

    I think you mean pettiest.

  • (nodebb)

    Without seeing the rest of the code we don't know if they released resources or not. There could be a finally block that does so. So if the retry macro goes to a line before the initial "try" statement, it could be workable. Not great coding, but it would likely solve the issue.

  • Bob Loblaw (unregistered)
    Comment held for moderation.
  • (nodebb)

    My guess is that retry is simply defined as throw via macro:

    #define retry throw

    An empty throw statement inside a catch block will re-throw the current pending exception, in which case that makes the entire exception handler completely useless. It doesn't solve the (alleged) deadlock, it doesn't log anything, it just pretends nothing happened.

  • f222 (unregistered) in reply to Auction_God
    Comment held for moderation.
  • (nodebb)

    Maybe they're just hoping that if they keep on retrying long enough, the other thread holding the resource will give it up first. The retry thingee, whatever it is, could suspend the calling thread long enough to give the other thread(s) enough time to finish up and release the resource.

    Please don't ask me how I know that this is a possibility.

  • (nodebb) in reply to Steve_The_Cynic

    Why the F isn't there a "Like" button on this comment board?

    For the same reason I can't tell which of my posts you were replying to.

  • (nodebb)

    ". . . give the other thread(s) enough time to finish up and release the resource." But it's a deadlock which means the other thread can't finish until it gets whatever resource that's being held by this "loop"

  • Hmmmm 🤨 (unregistered)

    Dare the "frist" crowd thrwo rocks at the "ot" poster??

    The code is great for its exceptional you-can't-make-this-stuff-up, unironic-but-not-hipster perfection! Who would think to catch a deadlock and then simply put "retry"??? Artistic genius!

  • COBOL Dilettante (unregistered) in reply to dpm
    Comment held for moderation.

Leave a comment on “Lock 'Em Dead”

Log In or post as a guest

Replying to comment #703741:

Log Out

« Return to Article