Something Strange

Whether you're a newbie or an experienced programmer, any questions, help, or just talk of any language will be welcomed here.

Moderator: Coders of Rage

Post Reply
Aleios
Chaos Rift Cool Newbie
Chaos Rift Cool Newbie
Posts: 78
Joined: Mon Feb 21, 2011 2:55 am
Current Project: Aleios Engine
Favorite Gaming Platforms: PC, Dreamcast
Programming Language of Choice: C++
Location: Melbourne, Australia

Something Strange

Post by Aleios »

Well, i just spent a few hours trying to debug my application, and i realized a possible issue in Visual Studio C++ as well as Human error.

So i am doing a bit of multi-threading and so i decided to write a few classes to keep the nasty disgusting windows/X api's away from me.

The classes i wrote were:
[*] Mutex
[*] Lock
[*] Thread

Mutex, when created (or constructed) on windows will initialize a "Critical Section" and contains the functions: Lock and Unlock. Which enter and exit the critical section respectively.

Now the Lock class takes a reference to Mutex in the constructor and locks it and then the destructor will Unlock the mutex. The lock class is to be used as a temporary as this allows for some prevention of deadlock when an exception occurs before you can call Unlock on the mutex (as temporary's live on the stack and die at function return).

Now look at this code:

Code: Select all

int Update()
{
   Lock lock(mutex);

   while(closing == false)
   {
     // DO shit
   }
   return 0;
}
That function is running on a separate thread. And i have a few other functions on the main thread for say, loading things.

Now notice here, the temporary cannot be killed off because the function does not return until the "closing" becomes true, so the mutex will NOT unlock. Oops, that's the human error!

Ok, so shit gets weird now. The program runs FINE... in the IDE. Outside the IDE, what occurs? oh deadlock! Now, that there is the IDE error.

So i was wondering, can anyone explain to me why the hell it runs perfect in the IDE, both when using the debugger and not using the debugger.
Image
User avatar
Falco Girgis
Elysian Shadows Team
Elysian Shadows Team
Posts: 10294
Joined: Thu May 20, 2004 2:04 pm
Current Project: Elysian Shadows
Favorite Gaming Platforms: Dreamcast, SNES, NES
Programming Language of Choice: C/++
Location: Studio Vorbis, AL
Contact:

Re: Something Strange

Post by Falco Girgis »

Aleios wrote:Ok, so shit gets weird now. The program runs FINE... in the IDE. Outside the IDE, what occurs? oh deadlock! Now, that there is the IDE error.

So i was wondering, can anyone explain to me why the hell it runs perfect in the IDE, both when using the debugger and not using the debugger.
That is not an "IDE error." Deadlocks aren't a guaranteed occurrence. Just because a portion of code can potentially deadlock does NOT mean that it WILL deadlock.

There are several external factors in action here. How are these parallel executing threads being scheduled? In what order are they executing? These are nondeterministic. They are internal to your operating system, and you have no control over them. They can be different every time your application executes. It is very much conceivable that whatever thread sets closing equal to true is given a chance to run before Update() is in certain situations.
Aleios
Chaos Rift Cool Newbie
Chaos Rift Cool Newbie
Posts: 78
Joined: Mon Feb 21, 2011 2:55 am
Current Project: Aleios Engine
Favorite Gaming Platforms: PC, Dreamcast
Programming Language of Choice: C++
Location: Melbourne, Australia

Re: Something Strange

Post by Aleios »

Ahh, now that is something i had no idea about. I had always assumed that threads were executed in some sort of set order. Seems i shall have to hit the books and study a lot more on threading.

But i am still a bit curious. Would there be anything at all that would cause the application to fail outside the ide, but not inside? Would the method of invoking the application cause a completely different result? or would it just simply be per execution.
GyroVorbis wrote: Deadlocks aren't a guaranteed occurrence.
I get this part now, but the thing is that whenever i had run it inside the IDE, it just never froze up. Threads ran as normal, maybe it was just luck, but executing the application around 50+ times without an occurrence? and then suddenly its happens outside the IDE? Hell, i might have accidentally supplied the outside executable with an older version of the dll.

Well in any case,
GyroVorbis wrote: There are several external factors in action here. How are these parallel executing threads being scheduled? In what order are they executing? These are nondeterministic. They are internal to your operating system, and you have no control over them. They can be different every time your application executes. It is very much conceivable that whatever thread sets closing equal to true is given a chance to run before Update() is in certain situations.
This helps me to start realizing that i really need to look more in depth as to what the operating system performs a bit better.

Thanks Gyro :)
Image
User avatar
Falco Girgis
Elysian Shadows Team
Elysian Shadows Team
Posts: 10294
Joined: Thu May 20, 2004 2:04 pm
Current Project: Elysian Shadows
Favorite Gaming Platforms: Dreamcast, SNES, NES
Programming Language of Choice: C/++
Location: Studio Vorbis, AL
Contact:

Re: Something Strange

Post by Falco Girgis »

You're right. It is still very strange that it ALWAYS acts a certain way outside of the IDE... I really don't have an answer for you. That's weird as hell... I mean, it's a definite deadlock, but anybody know why it is magically consistently scheduled in such a manner outside of the IDE? Anybody else have any ideas?
User avatar
short
ES Beta Backer
ES Beta Backer
Posts: 548
Joined: Thu Apr 30, 2009 2:22 am
Current Project: c++, c
Favorite Gaming Platforms: SNES, PS2, SNES, SNES, PC NES
Programming Language of Choice: c, c++
Location: Oregon, US

Re: Something Strange

Post by short »

A possibility,

within the IDE, did you try running it in both debug and release mode? If it only behaves OK in debug mode, but not in release mode I think that would point to compiler optimizations reordering your instructions in release mode.

You stated that you wrote your own mutex/lock/thread. It is very well possible the compiler is re-ordering your instructions (in release mode, subsequently outside of the IDE) around your mutex/thread/lock implementations for performance issues, but fucking up your synchronization. The volatile keyword will help with this, preventing any instruction reordering.
My github repository contains the project I am currently working on,
link: https://github.com/bjadamson
Aleios
Chaos Rift Cool Newbie
Chaos Rift Cool Newbie
Posts: 78
Joined: Mon Feb 21, 2011 2:55 am
Current Project: Aleios Engine
Favorite Gaming Platforms: PC, Dreamcast
Programming Language of Choice: C++
Location: Melbourne, Australia

Re: Something Strange

Post by Aleios »

Yep, i did try running in debug and release, same result. The program links to the proper DLL's meaning the debug vs release versions. However i have not tried making things volatile, except for that closing variable. I shall look into it!
Image
User avatar
k1net1k
Chaos Rift Maniac
Chaos Rift Maniac
Posts: 563
Joined: Sun Nov 07, 2010 2:58 pm
Contact:

Re: Something Strange

Post by k1net1k »

maybe the ide provides some sort of sandbox which does alter its behavior by putting in hooks for each line so the debugger can work. 'in the wild' code just gets executed
Aleios
Chaos Rift Cool Newbie
Chaos Rift Cool Newbie
Posts: 78
Joined: Mon Feb 21, 2011 2:55 am
Current Project: Aleios Engine
Favorite Gaming Platforms: PC, Dreamcast
Programming Language of Choice: C++
Location: Melbourne, Australia

Re: Something Strange

Post by Aleios »

k1net1k wrote:maybe the ide provides some sort of sandbox which does alter its behavior by putting in hooks for each line so the debugger can work. 'in the wild' code just gets executed
That's a possibility, but i guess it's not really something to get too caught up on. There is probably a most simple solution to my issue, "Don't lock something that can't be unlocked." That's the answer to human error, but i guess there truly must be something that the IDE does differently, through special hooks, or otherwise. Thanks :)
Image
Post Reply