Asynchronous design question
-
Are multimple threads allowed to access simultaneously the same method of an instance object? What happend then? they both run a different 'instance' of the method?
-
Are multimple threads allowed to access simultaneously the same method of an instance object? What happend then? they both run a different 'instance' of the method?
sb777 wrote: Are multimple threads allowed to access simultaneously the same method of an instance object? Yes sb777 wrote: What happend then? they both run a different 'instance' of the method? No, method variables lives on the stack, and each thread maintains its own stack. Example:
public class TestClass
{
public static int Test(int i)
{
int retval = i;
return retval;
}
}Let's assume that two different threads, tA and tB, invokes TestClass.Test: tA pushes the 'i' integer argument on its stack, let's say the value is 42, and then it invokes TestClass.Test. tB pushes the 'i' integer argument on its stack, let's say the value is 9, and then it invokes TestClass.Test. In both cases TestClass.Test makes room for the variable retval by pushing an integer to the stack of the current thread. It then sets the value of that integer to the value of i. And the value of i is found on the stack of the current thread. When you write 'return retval' you actually tells the compiler to push
retvalon the stack of the current thread. So, in the example above, nothing can go wrong in a multithreaded environment. Things are getting ugly if the example looks like this though:public class TestClass
{
private static int j;public int J
{
get:
{
return j;
}
set:
{
j = value;
}
}public static int Test(int i)
{
int retval = i;
return retval + j;
}
}Things are looking good right untill
retvalis added toj. The problem is thatjlives on the heap, so both threads will access the same reference toj. This is where you, the programmer, needs to actually think (ugh!). At some point in you code, you must find the sequence of code that isn't threadsafe, and then you must wrap it in alockblock like this:lock(aReferenceToAnObjectSharedByBothThreads)
{
TestClass.J = x;
int y = TestClass.Test(x + 1);
}"After all it's just text at the end of the day. - Colin Davies "For example, when a VB programmer comes to my house, they may say 'does your pool need cleaning, sir ?' " - Christian Graus
-
sb777 wrote: Are multimple threads allowed to access simultaneously the same method of an instance object? Yes sb777 wrote: What happend then? they both run a different 'instance' of the method? No, method variables lives on the stack, and each thread maintains its own stack. Example:
public class TestClass
{
public static int Test(int i)
{
int retval = i;
return retval;
}
}Let's assume that two different threads, tA and tB, invokes TestClass.Test: tA pushes the 'i' integer argument on its stack, let's say the value is 42, and then it invokes TestClass.Test. tB pushes the 'i' integer argument on its stack, let's say the value is 9, and then it invokes TestClass.Test. In both cases TestClass.Test makes room for the variable retval by pushing an integer to the stack of the current thread. It then sets the value of that integer to the value of i. And the value of i is found on the stack of the current thread. When you write 'return retval' you actually tells the compiler to push
retvalon the stack of the current thread. So, in the example above, nothing can go wrong in a multithreaded environment. Things are getting ugly if the example looks like this though:public class TestClass
{
private static int j;public int J
{
get:
{
return j;
}
set:
{
j = value;
}
}public static int Test(int i)
{
int retval = i;
return retval + j;
}
}Things are looking good right untill
retvalis added toj. The problem is thatjlives on the heap, so both threads will access the same reference toj. This is where you, the programmer, needs to actually think (ugh!). At some point in you code, you must find the sequence of code that isn't threadsafe, and then you must wrap it in alockblock like this:lock(aReferenceToAnObjectSharedByBothThreads)
{
TestClass.J = x;
int y = TestClass.Test(x + 1);
}"After all it's just text at the end of the day. - Colin Davies "For example, when a VB programmer comes to my house, they may say 'does your pool need cleaning, sir ?' " - Christian Graus
First, Thanks for your answer. Now, why did you use static method for your example? Is the same story true for instance methods?
-
First, Thanks for your answer. Now, why did you use static method for your example? Is the same story true for instance methods?
You're welcome. I used static, so I could skip the instantiation part of the code. Instance methods and instance member variables behaves just the same. "After all it's just text at the end of the day. - Colin Davies "For example, when a VB programmer comes to my house, they may say 'does your pool need cleaning, sir ?' " - Christian Graus
-
You're welcome. I used static, so I could skip the instantiation part of the code. Instance methods and instance member variables behaves just the same. "After all it's just text at the end of the day. - Colin Davies "For example, when a VB programmer comes to my house, they may say 'does your pool need cleaning, sir ?' " - Christian Graus
As I understand, there is no need to lock read-only (per method or general) members. Am I right?
-
As I understand, there is no need to lock read-only (per method or general) members. Am I right?
You're right. the readonly variables has to be initialized in the constructor, and no threads can change them. Problems in multithreaded environments starts, when a thread assumes something about a variable, that can be changed in between line x and line y by another thread. "After all it's just text at the end of the day. - Colin Davies "For example, when a VB programmer comes to my house, they may say 'does your pool need cleaning, sir ?' " - Christian Graus