Page 1 of 1
Something Strange
Posted: Tue Oct 11, 2011 5:02 am
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.
Re: Something Strange
Posted: Tue Oct 11, 2011 12:24 pm
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.
Re: Something Strange
Posted: Tue Oct 11, 2011 8:54 pm
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
Re: Something Strange
Posted: Tue Oct 11, 2011 10:25 pm
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?
Re: Something Strange
Posted: Wed Oct 12, 2011 12:23 am
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.
Re: Something Strange
Posted: Wed Oct 12, 2011 2:05 am
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!
Re: Something Strange
Posted: Wed Oct 12, 2011 3:34 am
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
Re: Something Strange
Posted: Wed Oct 12, 2011 6:06 pm
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