Sign in to follow this  

[.net] C# sux! Or I do?

This topic is 3713 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello, I have been programming a small simulator that models human population. This little exercise has seriously exposed my lack of understanding when it comes to OOP and how programs really run. For some reason, my program just gets out of sync. If you run it with a small population size its fine, but if i increase the population, it just gets messed up and i see no reason why this would happen. I have uploaded the finished program to a free file server (hope it works) and was hoping someone could download it. You just unzip and run, no need to install anything. Once its opened just type a number into the SEED box and hit the start button. If you put in say 50, it runs quite well. But put in 500 and for some reason, all the dates and ages get messed up. Obviously you cant tell me much without seeing my source and will upload that if anyone wants it. Just thought some old pros would know why this happens without even seeing the source. I typed 5000 into seed and it got to year 398 which is impossible because max lifespan is 100 and no one is breeding. As you can see, it just starts out with a population and it ages then dies. They should all be be dead by 100 but its as if my time labels are out of sync with my people ect ect but in the code that isnt possible because the time advances at the same time as i iterate through my population list. Sorry for rambling but any help would be greatly appreciated. Thanks :) Here is the link: www.yourfilelink.com/get.php?fid=394738

Share this post


Link to post
Share on other sites
Ok, first things first:
You have a member variable "ppl" that is used in exactly one function, your backgroundWorker1_DoWork method. Eliminate that and make it a local.

As far as your bug goes, I've looked through your source and don't see what could be causing it. I would suggest running through it with an interactive debugger.

Share this post


Link to post
Share on other sites
Thanks Washu.

I have debugged it and the variables do what they are supposed to do. It is only when it goes fast that it loses the plot.

It doesnt seem to be a logic bug or code bug but more of an issue on how the .net platform runs. Well, as far as i can tell anyway. It seems like threads get out of sync or something but all my code runs in one thread and the ui in another.

I might play arount with timers or something.

Share this post


Link to post
Share on other sites
It's not how the .net framework runs that's affecting it. The only piece of code that can affect your counters is the background worker thread (assuming no bugs). Since that's the case, it's YOUR code that's running past 100.

Share this post


Link to post
Share on other sites
Didn't checked your code yet...
But a little hint: if you are using multiple threads (which seems to be the case) be sure you handle correctly the data access over the threads, that means if a thread need to modify the data, use a lock, and use the same lock to read the data, so you are sure you don't have two thread trying to access the data at the same time:

class myClass
{
int myInt;

public void FunctionInThreadA()
{
lock (myInt)
{
myInt++;
}
}

public int FunctionInThreadB()
{
lock (myInt)
{
return myInt;
}
}
}

Share this post


Link to post
Share on other sites
Quote:
Original post by a_bertrand
Didn't checked your code yet...
But a little hint: if you are using multiple threads (which seems to be the case) be sure you handle correctly the data access over the threads, that means if a thread need to modify the data, use a lock, and use the same lock to read the data, so you are sure you don't have two thread trying to access the data at the same time:
...code...

Wouldn't the example code be locking a new boxed instance of the value type each time? I could be totally wrong, but I think this is what happens when locking an instance of a value type.

Share this post


Link to post
Share on other sites
Quote:
Original post by dalleboy
Quote:
Original post by a_bertrand
Didn't checked your code yet...
But a little hint: if you are using multiple threads (which seems to be the case) be sure you handle correctly the data access over the threads, that means if a thread need to modify the data, use a lock, and use the same lock to read the data, so you are sure you don't have two thread trying to access the data at the same time:
...code...

Wouldn't the example code be locking a new boxed instance of the value type each time? I could be totally wrong, but I think this is what happens when locking an instance of a value type.


That is (partially) correct.

class Dangerous
{
public bool x;

public void foo()
{
Monitor.Enter(x); // New boxed instance of x created, locked
x = true;
Monitor.Exit(x); // *New* boxed instance of x created, tries to unlock
}

public void bar()
{
Monitor.Enter(x); // *New* boxed instance of x created, locked
x = false;
Monitor.Exit(x); // *New boxed instance of x created, tries to unlock
}
}






Not a single one of these instances is the same: i.e., there is absolutely no thread safety there at all. Also, you'll throw a SynchronizationLockException every time you try to unlock using a new boxed instance.

However,

class Dangerous
{
public bool x;

public void foo()
{
lock (x) // Compile-time error
x = true;
}

public void bar()
{
lock (x) // Compile-time error
x = false;
}
}






Must read

Specific quote:

Quote:
As I said, it took me several hours to discover this problem. If you want to synchronize access to an unboxed value type instance, then you must allocate a System.Object object and use it for synchronization. The code in Figure 10 is the corrected code.


(emphasis mine)

Share this post


Link to post
Share on other sites

This topic is 3713 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this