.NET Multithreading Syncronization

views:

answers:

.NET Multithreading Syncronization

Quick version of my question:

Is the only time you need to use "lock" when you are accessing the same instance of an object? For example, if i am instantiating everything new within my thread entry method, do I have to worry about locking any objects?

Detailed Explanation of my question:

My scenario is, I have a work object with a unique identifier, and that work object has 1 method in it. Inside that method, I create new instances of multiple web service proxies and store the information retrieved from those calls in public properties of the work object. Once all work has been done (all threads have finished), I store the information to a database.

Any reason to consider using "lock"?

...if i am instantiating everything new within my thread entry method, do I have to worry about locking any objects?

Nope.

Is the only time you need to use "lock" when you are accessing the same instance of an object?

Yep.

musicfreak 2009-10-22 02:09:28

To complicate it further, lets say I'm accessing a static method within my thread but inside that method, I create new instances, do I still not need to worry? Here is the execution flow:Controller starts thread at ThreadEntry() calls static InvokeService() creates new instance of proxy

Benny 2009-10-22 02:15:24

As long as all new instances are thread-specific and no other thread accesses them, you do not need locks.

musicfreak 2009-10-22 02:16:15

Oh, and @SLaks is right, make sure `InvokeService` does not access any static members.

musicfreak 2009-10-22 02:19:10

You're quite right - you don't need to lock objects that are not accessed across threads.

However. Be careful that there are no global resources, (i.e. I/O streams), that are been accessed by multiple threads without synchronization.

ahosie 2009-10-22 02:14:42

In regards to I/O streams, the closest I possibly will come to that is that my thread entry method also accesses web sites to parse data. I am creating a `StreamReader` that parses out values from a HttpWebResponse object.

Benny 2009-10-22 02:25:23

+1 A:

You only need to use lock on one or more sections of code that should not be run simultaneously. For example, if you have code that uses the same List<T> on multiple threads, you would need to use a lock.

In your case, if you have a separate work object per thread, and if they don't interact with any other work objects or access any shared state, you should be fine.

For a more specific answer, please post more details, or, preferably, source.

EDIT: In response to your comment, it depends on the implementation of InvokeService. As long as it doesn't access any other static members, you'll probably run fine without any locks.

SLaks 2009-10-22 02:15:00

You only need to use the lock keyword if you are accessing a static field or property from multiple threads.

David 2009-10-22 02:33:42

To be explicit, only use lock when accessing static fields and properties. It is not needed for static methods?

Benny 2009-10-22 02:36:08

It depends what the static methods do.

SLaks 2009-10-22 02:44:58

Being static has nothing to do with it (although it is a very common cause of "thread-hostile code"). References to the same object can end up in different threads in other ways as well (e.g. fields in a runnable class executed by multiple threads)

Wim Coenen 2009-10-22 03:11:42

wcoenen. so what if a class with non static members is accessed by multiple threads? as long as the fields are instance, they will each have their own heap memory and therefore not need synchronization. Am I missing something here?

David 2009-10-28 01:21:54

Interesting wcoenen. I think I see what you mean.public class Dummyclass{ public int A = 0; public int B = 0;}DummyClass instance = new DummyClass();for(int i = 0; i < 10; i++){ Thread t = new Thread(callBack); ThreadStart ts = new ThreadStart(t); ts.Start(instance);}private void callBack(DummyClass instance){ instance.A++; instance.B++;}It makes sense because all threads have the same reference on the stack, hence pointing to the same heap memory, hence needing synchronization. IME more common threading issues come around when using static data.

David 2009-10-28 01:29:18

Slaks - only if the static methods access static data. Otherwise not needed. In what other case would a static method need synchronization?

David 2009-10-28 01:30:22

Slaks - (other than accessing static data).

David 2009-10-28 01:31:03

ansaurus

tags:

views:

answers:

.NET Multithreading Syncronization

related questions