Allegro.cc - Online Community
Post Reply

Allegro.cc Forums » Allegro.cc Comments » Thread locks too soon

rss feed Print
Thread locks too soon
Chris Katko
Member #1,881
January 2002
avatar

Glad you're not in it now. :( There's been like 15 dead so far.

Then again (not to be morbid or anything), any disaster, somebody always manages to find a way to die. For example, "It's hot out today" = "20 dead." somehow.

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs

Eric Johnson
Member #14,841
January 2013
avatar

Then again (not to be morbid or anything), any disaster, somebody always manages to find a way to die. For example, "It's hot out today" = "20 dead." somehow.

Yeah, that's true. People die every day. Still, it sucks to see businesses and neighborhoods you once frequented become ash and rubble. I checked in with some of my friends who still live there, and the ones who got back to me say they're okay. Still waiting to hear from a few others though.

Chris Katko
Member #1,881
January 2002
avatar

Hope everything works out. :-/

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs

Bruce Perry
Member #270
April 2000

Pro tip: don't watch the Final Destination films immediately prior to reading the above posts :-X

--
Bruce "entheh" Perry [ Web site | DUMB | Set Up Us The Bomb !!! | Balls ]
Programming should be fun. That's why I hate C and C++.
The brxybrytl has you.

Onewing
Member #6,152
August 2005
avatar

------------
Solo-Games.org | My Tech Blog: The Digital Helm

bamccaig
Member #7,536
July 2006
avatar

From the looks of it that thread was only revived once with only a handful of posts (unless ML deleted other posts?). Seems like a bit of an overreaction. :P

Chris Katko
Member #1,881
January 2002
avatar

I honestly recall overreactions happening at least a few times back-in-the-day.

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs

Edgar Reynaldo
Member #8,592
May 2007
avatar

This is actual code. I shit you not.

{"name":"611079","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/e\/ee446f78e8bb7f042ffba76e46288a7c.png","w":441,"h":135,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/e\/ee446f78e8bb7f042ffba76e46288a7c"}611079

Bruce Perry
Member #270
April 2000

Written by a smoker. They'll tell you they're quitting but they know they aren't, so they stay stuck in the loop for ever. :)

--
Bruce "entheh" Perry [ Web site | DUMB | Set Up Us The Bomb !!! | Balls ]
Programming should be fun. That's why I hate C and C++.
The brxybrytl has you.

Edgar Reynaldo
Member #8,592
May 2007
avatar

Chris Katko
Member #1,881
January 2002
avatar

I'm at a loss. What's wrong with it?

(Except for the fact you're not using Whitesmith's style. ;) )

https://en.wikipedia.org/wiki/Indentation_style#Whitesmiths_style

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs

Edgar Reynaldo
Member #8,592
May 2007
avatar

Neil Roy
Member #2,229
April 2002
avatar

Written by a smoker. They'll tell you they're quitting but they know they aren't, so they stay stuck in the loop for ever. :)

Except in this case, it will exit right away without ever running through the loop (`quit` is set to true).

I'm at a loss. What's wrong with it?

well they set quit = true then they exit the loop if quit is not false. The program won't go through the loop even once, it will just exit right away.

quit should be set to false when it is initialized.

The only way I could see doing this without changing quit initialization, would be to use a do while loop so it is run at least once, and perhaps change quit in the loop if needed.

Well it took me a week's worth work to find it. Last place I ever thought to look.

It's always the little things that take the longest to spot.

Edgar Reynaldo
Member #8,592
May 2007
avatar

Neil Roy
Member #2,229
April 2002
avatar

bamccaig
Member #7,536
July 2006
avatar

Neil Roy said:

It's always the little things that take the longest to spot.

Disagreed. The little things take longer than they should to spot, but the big things are much more difficult to reason about. :) Threads and race conditions and things of that nature.

Bruce Perry
Member #270
April 2000

Yeah, I spotted the fact that it would exit immediately - my post was a joke, admittedly a terrible one, to try to justify why the code might be written that way ;)

I suspect this bug could have been found very quickly with the help of a debugger - just step through from the beginning and see what it does. If you don't have a debugger set up, then get one set up :)

--
Bruce "entheh" Perry [ Web site | DUMB | Set Up Us The Bomb !!! | Balls ]
Programming should be fun. That's why I hate C and C++.
The brxybrytl has you.

Edgar Reynaldo
Member #8,592
May 2007
avatar

bamccaig
Member #7,536
July 2006
avatar

Those are difficult to reason about. When the seemingly "impossible" occurs. When you're certain that a block of code must be reached, but the debugger shows it skipped over. I think there's circuitry in our brains that make us susceptible to the notion of "supernatural" occurrences. When these "paradoxes" occur the logical thing is to realize that our assumptions are wrong and reassess our understanding of the program, but often we just scratch our heads and think "WTF, this can't happen, even though it does!" instead. These are the moments where telling just about anybody else about it will immediately solve the problem: either you'll realize, hold on, maybe my assumption is wrong, or the other person will ask questions trying to understand what you're talking about that force you to discover it by mistake.

jmasterx
Member #11,410
October 2009

bamccaig said:

Those are difficult to reason about. When the seemingly "impossible" occurs. When you're certain that a block of code must be reached, but the debugger shows it skipped over. I think there's circuitry in our brains that make us susceptible to the notion of "supernatural" occurrences. When these "paradoxes" occur the logical thing is to realize that our assumptions are wrong and reassess our understanding of the program, but often we just scratch our heads and think "WTF, this can't happen, even though it does!" instead. These are the moments where telling just about anybody else about it will immediately solve the problem: either you'll realize, hold on, maybe my assumption is wrong, or the other person will ask questions trying to understand what you're talking about that force you to discover it by mistake.

Wrong. All processor manufactures have just implemented their instruction set incorrectly resulting in your software misbehaving.

As a result you as a developer are stuck making compromises for their petty mistakes and oversights
When you discuss it with someone, all they're doing is telling you from their experience how they got around the processor manufacturing defects. >:(

Edgar Reynaldo
Member #8,592
May 2007
avatar

Chris Katko
Member #1,881
January 2002
avatar

I suspect this bug could have been found very quickly with the help of a debugger - just step through from the beginning and see what it does. If you don't have a debugger set up, then get one set up :)

Yeah, that definitely seems like a case for the step functionality of a debugger if you're going in blind and have no idea why.

Also, both many static analyzers and whatever Visual Studio's IDE is, would have caught that. VS would have said "warning: this code can never be reached." (Actually, don't many compilers say that with -Wall?)

And many linters/static analyzers will actually read things like variable names and their initial values and say "Are you sure this is what you meant?". Like creating an integer but calling it test_float.

They also do this amazing case:

for(int i=0;i<my_long1.thing_dot.count();i++)
for(int j=0;j<my_long2.thing_dot.count();i++)
for(int k=0;k<my_long3.thing_dot.count();k++)
for(int l=0;l<my_long4.thing_dot.count();l++)
{
access_my_thing[i][j][k][l];
}

As well as:

for(int i=0; i<100; i++)
for(int j=0; j<100; j++)
{
my_data[1][j].access.here();
}

And a huge swath of other things, many major, but also many minor ones that your eye tricks you into missing by autocorrecting.

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs

Edgar Reynaldo
Member #8,592
May 2007
avatar

To all those suggesting I use a debugger - I do! -Wall does NOT warn about while (false).

But somethings are harder to step through when you have an interactive program.

In this case, I was spawning a new thread that creates a window and draws to it, but the window kept closing as soon as it was opened. Which made me think it was getting a close event. Or the thread was signaled to stop for some reason. I thought for sure it was one of the loop's break conditions getting triggered.

bamccaig
Member #7,536
July 2006
avatar

Edgar Reynaldo
Member #8,592
May 2007
avatar

Post Reply


Go to: