Weird Xp/Win7 bug

[ahottev]

In my MainMenu class, i have this line, which waits for a player selection:

while(  (selectedWorld == -1)  &  (editSelectedWorld == -1)  ){}

In windows Xp, it works. Now, i've tried it on my laptop at home, using Win7, 64 bits, and there's no way it'll work. It simply doesn't seem to test either values.

But, if i add:

while(  (selectedWorld == -1)  &  (editSelectedWorld == -1)  ){

     System.out.println( selectedWorld + "," + editSelectedWorld );

}

It works. 
Is there any reason for that?

[cylab]

Weird Xp/Win7 bug

It's not a bug, it's your own fault...

Is there any reason for that?

I guess this is a multithreaded application and the selectedWorld and editSelectedWorld variables are updated from another thread. Since you do not synchronize the access to the variables, you might just read out the values from the cpu-cache and not the actual ones (maybe because they are updated from the other cpu on your laptop - I bet you have a dual-core laptop...).

Anyway thread safe access to ints is afaik (at least theoretically) platform dependent and should be avoided. You could get away with declaring them volatile, but I wouldn't bet on it. Learn about thread safe programming using the synchronized keyword and you will be fine.

On a sidenote: the logical AND operator in java is &&. A single & is a binary AND, which might do something completely different than you expect...

[ahottev]

It's not a bug, it's your own fault...

I guess this is a multithreaded application and the selectedWorld and editSelectedWorld variables are updated from another thread. Since you do not synchronize the access to the variables, you might just read out the values from the cpu-cache and not the actual ones (maybe because they are updated from the other cpu on your laptop - I bet you have a dual-core laptop...).

Anyway thread safe access to ints is afaik (at least theoretically) platform dependent and should be avoided. You could get away with declaring them volatile, but I wouldn't bet on it. Learn about thread safe programming using the synchronized keyword and you will be fine.

On a sidenote: the logical AND operator in java is &&. A single & is a binary AND, which might do something completely different than you expect...

Well, no, it's not a multithreaded application. My laptop is dual-core (win7) and my other pc is quad core (but it has winXP installed), but nothing is actually multithreaded in my application. Unless you mean windows decides to multi-thread things without me knowing it?

About the '&', the way i understood it, a binary AND would test both values before continuing where a logical AND &&  will only test the first one?

Games published by our own members! Check 'em out!

[cylab]

If it's not multithreaded, what is

1	while(  (selectedWorld == -1)  &  (editSelectedWorld == -1)  ){}

supposed to do then? 

Unless you mean windows decides to multi-thread things without me knowing it?

Not Windows, but java if you use a Swing/AWT, because the event handling runs on it's own thread, the AWT Event Thread or EDT (Event Dispatcher Thread)

About the '&', the way i understood it, a binary AND would test both values before continuing where a logical AND &&  will only test the first one?

A binary AND combines bit-pattern, a logical AND combines boolean expressions. That are different things - don't use the one for the other. A logical AND will not test the second expression if the first one evaluates to false, simply because it doesn't have to - (false AND true) would be false in the end anyway. This is called shortcut evaluation and is a GoodThing (TM). It will however test the second expression, if there is a chance that the whole expression could evaluate to true.

[ahottev]

If it's not multithreaded, what is

1	while(  (selectedWorld == -1)  &  (editSelectedWorld == -1)  ){}

supposed to do then? 

Nothing   As you said, it's a Swing menu, so it's just waiting for the player to press either the world to play in, or select the editor to edit a a world. Once pressed, a JButton returns selectedWorld == 3 for example, if the user wishes to play in world 3.

Both values start a -1 since neither a world or an editor is selected.

Yeah, i know it's not the best approach, but at the time it seemed like a quick and working way of doing it...

Not Windows, but java if you use a Swing/AWT, because the event handling runs on it's own thread, the AWT Event Thread or EDT (Event Dispatcher Thread)

Hum... i'll have to check that now, thanks.

[cylab]

Also doing this kind of loop drives your cpu-usage to 100% and makes your machine slow and slugish. You should use a Thread.sleep(100); or something inside the loop. Also make sure you are accessing the variables in a thread safe manner using synchronized(someFinalObject){yourCrossThreadVariableAccess} - but DON'T put the whole while-loop in a synchronized .

[Abuse]

In this instance I suspect an object lock (monitor) along with a wait/notify would be the correct solution.

[JL235]

As others have pointed out if your using Swing then your building a multi-threaded app. Typically you don't need to care (all your stuff is within action listeners called at the correct moment) but if your waiting on something then you do.

Someone suggested using Thread.sleep above, I second this.

Lots of naive programmers (including myself) also fall into the trap of using Thread.yield instead (thinking yielding to another thread will be better then sleeping); just as a word of advice make sure you don't do this either!. Yielding works fine on Vista and Win7 but on any other OS it's the same as spinning inside a while loop.