• (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)

    meanwhile, earlier in the code:

    int retry = 0;

  • (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

    A finally block in CPP ? Nope that doesn't exist. The code is definitely a mess :D

  • (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

    I like hendiadys; I find it nice and easy

  • Argle (unregistered) in reply to Auction_God

    I think you mean pettiest.

    I think that would be something nearly the opposite of the original intent.

  • Klimax (unregistered) in reply to dpm

    Under "in reply to" is hiding a link to that post...

  • (nodebb) in reply to dpm

    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.

    I think the reasons are slightly different. The second piece of functionality (telling which of one's posts someone is responding to) is supported by the forum software: you click on the "in reply to..." text and it takes you to the original. It's not obvious though. Whereas the first piece of functionality ("liking" someone's post) simply isn't supported.

    However, the underlying reason is the same for both: custom software built without full consideration of the users' needs.

  • (nodebb) in reply to Klimax

    Under "in reply to" is hiding a link to that post...

    I meant, and should have said, "visually".

  • (nodebb)

    IANA C++ dev. If two threads are deadlocked, which thread is the exception and exception handling running on? And how are deadlocks detected?

  • Jason Stringify (unregistered) in reply to dpm

    "Try and ..." is a well-established idiom that has been used in English for hundreds of years.

  • TechHound (unregistered) in reply to dpm

    I meant, and should have said, "visually".

    If someone quotes the post they're replying to, you can see it, otherwise the "in reply to" line with a link is a good indicator; you can click it and see the post for context, and go back, it's not difficult.

  • Rod (unregistered) in reply to WTFGuy

    which thread is the exception and exception handling running on Whichever thread throws the exception.

    And how are deadlocks detected? They're not. That looks like a custom exception type; someone must have written code to throw it...

  • Fizzlecist (unregistered) in reply to Steve_The_Cynic

    👍

  • (nodebb) in reply to Steve_The_Cynic

    Clearly it's not "try and fix" because the HPC didn't fix all of them

    It might be a short circuiting and.

Leave a comment on “Lock 'Em Dead”

Log In or post as a guest

Replying to comment #703797:

Log Out

« Return to Article