Multi-Threading Question

  • Thread starter Thread starter Cool Guy
  • Start date Start date
C

Cool Guy

(In thread A.)

{
Bar bar = new Bar();
lock (fooLock) {
foo = new Foo(bar); // is value of *bar* current here?
}
}

(In thread B.)

{
lock (fooLock) {
foo.DoSomethingWithBar(); // is *bar* value correct when used here?
}
}

Basically, an object which is accessed in multiple threads is being given a
reference to a local variable.

Will the lock in the above guarantee that the local variable's value, upon
reading, is current -- and that foo's bar reference is correct?

I assume so but I've never really thought about local variables in this
situation before.
 
Local variables are always thread-safe, since they are not shared among
threads. This is because each thread has its own stack (where the local
variables are stored).
 
- said:
Local variables are always thread-safe, since they are not shared among
threads. This is because each thread has its own stack (where the local
variables are stored).
Click to expand...

That's certainly true. However, if the local variable is a reference to
an object which is also being used and potentially changed on another
thread, you need to use locks, volatile variables or explicit memory
barriers to ensure safety.
 
Hmmmm - be careful, in C# 2.0 anonymous delegates change the landscape a bit. Variables that appear to be local turn out to be allocated on the heap.

void DoIt()
{
int x = 0;
MyDel d = delegate
{
for( int i = 0; i < 2000; i++ )
{
x += i;
}
};
IAsyncResult ar = d.BeginInvoke(null, null);
x++;
d.EndInvoke(ar);
}

In x is now being updated from 2 threads and is (under the covers) being allocated on the head in a temporary object.

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

Local variables are always thread-safe, since they are not shared among
threads. This is because each thread has its own stack (where the local
variables are stored).
 
Jon Skeet said:
That's certainly true. However, if the local variable is a reference to
an object which is also being used and potentially changed on another
thread, you need to use locks, volatile variables or explicit memory
barriers to ensure safety.
Click to expand...

In this case it's never being changed, although it is being used on another
thread.

Will the locking I'm already doing suffice here?
 
Cool Guy said:
In this case it's never being changed, although it is being used on another
thread.

Will the locking I'm already doing suffice here?
Click to expand...

Yes, that's fine. By the time you release the lock in thread A, all the
writes are guaranteed to be visible to other threads, and by the time
you've acquired the lock in thread B, thread B is guaranteed to only
use values which are "correct" as of the time of the lock acquisition.
 
Back
Top