is this thread safe???

Started by
8 comments, last by Zweistein2 13 years, 3 months ago
im thinking of making a part of a game im starting in threads.
but i dont have mach exp in threading and how data moves between them.
in a c# book i have it says the next code if safe.
iw works but im not so sure how this will scale up to big game arrays.

T t;
public int b = 0;

void button1_Click(object sender, EventArgs e)
{
int a = 0;
t = new T();
new Thread(t.run).Start();

while (a < 1000000)
{
a++;
}

label1.Text = a + "";
label2.Text = b + "";
t.stop = true;
a = 0;
}

public class T
{
public int a = 0;
public bool stop = false;

public void run()
{
while (a < 1000000 && stop==false)
{
a++;
Program.f.b = a;
}
a = 0;
}
}

this code just accesses public vars with no locks or anything and "freely" talks between threads. am i wrong here in some way?
Advertisement
Lovely naming of variables there...

I'm not 100% sure that code is entirely thread safe. It's not my forte, but I'm reasonably certain that if it isn't, it's not safe in a nice sane manner (in the main thread, when you assign b to the label, it might be an 'old' value... which doesn't matter here).

I'm mildly curious what book contains this as example code.
as for the b var it cannot be and old result coz there is none and the results are too consistent(no not the exact same number)
and as for the book, i made the example a tad bigger so i can see timing too!
There isn't any talking going on between anything in the code you posted. If you want threads to know the status of another thread, there are a couple of ways. For example, if you want thread A to know if thread B has finished some work you can use a simple global boolean that when thread B finishes, it sets the bolean to false. This will work because you dont care about the specific value of the bolean, just that it is non zero or zero.

In any event, the code you posted seems very strange to me because there seems to be useless stuff in there that makes me wonder exactly what you are trying to keep thread safe. Making a function thread safe can be done in many different ways depending on alot of factors.
Wisdom is knowing when to shut up, so try it.
--Game Development http://nolimitsdesigns.com: Reliable UDP library, Threading library, Math Library, UI Library. Take a look, its all free.
Quote:Original post by kalixxx
as for the b var it cannot be and old result coz there is none and the results are too consistent(no not the exact same number)


This is not a guarantee of thread safety.

well ill try makeing a new thread here when ill finish some stuff.
but im trying to make a space game with all the player/ship info is on an array
most of the components in the game need to know whats in there!
i need to know how different threads can talk to the same array without bonking there heads!
If you don't want your threads bumping heads then you need to lock the critical sections. Have a look here on how to do it: http://msdn.microsoft.com/en-us/library/c5kehkcz%28v=VS.100%29.aspx

Just as a side note and some friendly advice; you need to ask yourself one questions. If you came back six months from now would you know what that code means? Always name your variables, functions, etc. to what their purpose is. If you put that code away for a while and came back you would have a hard time understanding it. Just some advice.

Best of luck.
I have no idea what you are trying to do here, but use volatile keyword for all variables that are accessed by more than one threads. Here's more information about volatile keyword:
http://msdn.microsoft.com/en-us/library/x13ttww7(v=vs.71).aspx

However, volatile is for primitive data types only. Don't use it for objects or arrays. Proper locking mechanism is more suitable for complex data structures.
some general tips:
- give variables descriptive names
- no global variables
- no member should be public(especially in a multi threading environment). C# has getter setter for this
-get into Object Orientated Programming(talking about your giant array of game data)
Incrementing is not threadsafe, because it has more than one instruction:

register = a;
register = register + 1;
a = register;

between loading the variable and storing it again there might be another increment from another thread. That gets overwritten by this. That for you have Microsoft InterlockedIncrement Functions.

(only applies if you do it, i didn t get your code right actually)

[Edited by - Zweistein2 on December 27, 2010 5:01:02 PM]

This topic is closed to new replies.

Advertisement