Variable ghosts

B

bri189a

Senior Contributor
Joined
Sep 11, 2003
Messages
1,004
Location
VA
I saw an article that explained why this happens, trying to find...does anyone know what I'm talking about:

C#: 
int index = 1;
while(index < 10)
{
   int i;
   if(index % 2)
   {
      i = index;
   }
   Console.WriteLine(i);
   index ++;
}

Worse case Output:
0
2
2
4
4
6
6
8
8
10

Let me stress that this isn't an exact output everytime - it's worse case...but make the loop big enough and let it run enough times and you'll see it.

What I'm getting at is that occasionally you see these 'variable ghosts' when you code like this. I know not to do this because I've run into it before, but yesterday I had a co-worker who ran into a similiar variable where at the class level he had a boolean value that he wasn't explicitly setting to false when declaring it. This was on a asp code behind. This resulted in occasionally the variable still being set to true from a (recent) previous call to the page. He couldn't understand why this is happening; I know it has something to do with GC and finalization que, but I can't find the article for the life of me and he really wants to understand why this is happening, so if you know where it is or can give a better explanation that what I just did, let me know.

Thanks
 
Sounds like some kind of race condition or threading issue.

With that code you provided, I don't think that can possibly happen. Simply put, a computer couldn't run if it were that unreliable. It can happen as a result of logic error, or poorly coordinated multithreading (which is also, ultimately, a logic error). If these were class-level variables we were working with, it is very possible to have a very hard to find bug that can result in this kind of behavior. When dealing with pass-by-reference parameters this sort of thing can happen very easily. But I've never seen any actual instance of something so simple malfunctioning in such a manner (in other words, I've never seen a computer execute in a manner that blatantly defies the logic of the code).

I've seen a similar article but it is only a vague memory and I can't recall the circumstances under which this kind of behavior was observed.
 
You're right...can't possible happen, but I was trying to illustrate the symptoms...without sending the actual program I don't know how else to do it. But at least you saw an article too so I know I'm not crazy.
 
I totally agree. There has to be an explanation for this. I'm just speculating here...

What if there's some kind of unknown optimization that is making this possible? My first impression was that i's memory was being reused without clearing it. This would make sense if you didn't declare i within the loop but unfortunately you are declaring i within the loop. So, maybe the compiler is doing something helpful that you are unaware of? Then again, the fact that it doesn't happen every time would be a good indicator that this isn't as simple as reusing memory.

I tried to run an experiment with the code you posted but I think my safety settings are set too high to allow that code to compile on my machine.
 
If you are bringing multiple threads into the equation then that changes everything. Multiple threads will require you to provide synchronisation whenever you access a resource from more than one thread.
 
Wasn't multi-threading. I can't give out the source code that does this, but I'm checking with a friend later this week to see if he can remember the exacts of how we got to occur elsewhere that was a lot simpler of a situation. I really think it has to do with the way a page is parsed and the internal page class is disposed. I mean ASPNET handling requests aren't all on the same thread, so that would be a possiblity maybe?
 
Back
Top