Integer not incrementing in Windows Vista, is in XP Pro/Home

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have a Net 2.0 app in VB that has code like this:

Dim intA as Integer
Dim intB as Integer
dim myList as new List(Of String)

intA = 10
intB = 20

.... code to fill the list ....

intA = intA + 1
intB = intB + 1

Then I insert into a list of type String, like so:

myList.Insert("the value being inserted here is " & intA, intB)

On XP Pro/Home, the list inserts using intA = 11 and intB = 21.
But on Vista, my beta users report that the Insert is using the previous
values 10 and 20 respectively. I am unable to recreate this problem myself
on Vista.

Does anyone have insight as to why this is happening? Thank you in advance.
 
Sounds odd, I suspect it is something else in the app or the way the
customers use it that is affecting this.
The best thing would be to run your app through the debugger at a 'tame'
customers site and see wether the integers are not incrementing or are being
added to the list incorrectly

Oh, and turn Option Strict on!

Guy
 
Mike said:
I have a Net 2.0 app in VB that has code like this:

Dim intA as Integer
Dim intB as Integer
dim myList as new List(Of String)

intA = 10
intB = 20

... code to fill the list ....

intA = intA + 1
intB = intB + 1

Then I insert into a list of type String, like so:

myList.Insert("the value being inserted here is " & intA, intB)
Click to expand...

You are certainly not.

The Insert method takes two parameters, where the first is an integer
and the second is a string.
On XP Pro/Home, the list inserts using intA = 11 and intB = 21.
But on Vista, my beta users report that the Insert is using the previous
values 10 and 20 respectively. I am unable to recreate this problem myself
on Vista.

Does anyone have insight as to why this is happening? Thank you in advance.
Click to expand...

Without seeing some of the code that you are actually using, it's very
hard to even have an idea about what's happening.
 
Göran Andersson said:
You are certainly not.

The Insert method takes two parameters, where the first is an integer
and the second is a string.


Without seeing some of the code that you are actually using, it's very
hard to even have an idea about what's happening.
Click to expand...

My mistake; I reversed the arguments of myList.Insert as I typed my
question. However the arguments' order are correct in my code.
The main point is why the Insert method would use the integers' previous
vakues.

I've learned that the problem machine is running 64-bit Vista on a 64-bit
dual-core machine. I am looking into whether dual-core is the problem or not.
 
Hello,

are you, by any chance, doing this stuff in paralell on multiple threads?

If so, you must protect access to the list with some sort of locking
mechanism (SyncLock statement in VB). Otherwise you might end up with a
race condition which might or might not occur on a single processor machine.

Kind regards,
Henning Krause
 
Henning Krause said:
Hello,

are you, by any chance, doing this stuff in paralell on multiple threads?

If so, you must protect access to the list with some sort of locking
mechanism (SyncLock statement in VB). Otherwise you might end up with a
race condition which might or might not occur on a single processor machine.

Kind regards,
Henning Krause
Click to expand...

Henning, thanks for replying. The problem code is on the main thread. I do
have another thread on which most my other methods run on, but they don't
read or write the 2 problem integer variables.

Even though it's on the main thread, I'll try wrapping the code in SyncLock
anyway to see if that makes a difference.

Thanks.
 
Mike said:
Henning, thanks for replying. The problem code is on the main thread. I do
have another thread on which most my other methods run on, but they don't
read or write the 2 problem integer variables.

Even though it's on the main thread, I'll try wrapping the code in SyncLock
anyway to see if that makes a difference.

Thanks.
Click to expand...

Putting a SyncLock around a single piece of code only has any effect if
more than one thread is using that code. If only the main thread is
using that code, it doesn't make any difference.

You can spend the time to try it, though. If it makes any difference,
there are two possibilities. Either that more than one thread is using
the code, which means that there is something wrong with your threads,
or that it changed the execution time, which means that it's a race
condition between threads.
 
Mike said:
My mistake; I reversed the arguments of myList.Insert as I typed my
question. However the arguments' order are correct in my code.
The main point is why the Insert method would use the integers' previous
vakues.
Click to expand...

If you did paste the actual code, it might be possible to spot the
problem right away. It might be a very simple mistake in the code, but
as noone other than you can see the code, we're just guessing here.

The code that you have written in the post is too incomplete to make any
sense anyway. You are inserting an item at index 20 in an empty list,
which is of couse not possible at all.
 
I have a belated update to this issue.

I fixed it by adding a call to MemoryBarrier between the last variable
assignment and the myList.Insert method. This was an issue on Vista running
64-bit dual core Athlons. The issue did not occur on Vista running 64-bit
dual core Pentiums, or any single core platform.

Thanks all for your assistance.
 
Back
Top