About Shared And SyncLock

[Henri]

1) Do Shared methods always need to be synchronised to be thread-safe?
2) Why must SyncLock be used with a reference type? I can't get the relation
between threads and a type.

Thanks for your help.
Henri

[Scott Allen]

1) Not always. If you have any Shared fields on the type and you are
both reading and writing them, then probably. Thread safety is needed
when you are sharing data between threads.

2) Threads are an abstraction that 'execute' code. Types are an
abstraction that 'contain' code. You can have multiple threads
executing the same code inside of a type concurrently. If you have
data that can be touched by multiple threads, you have to be careful
that two threads are not changing an ArrayList, for example, at the
same time, because it leads to unpredictable behavior and you spend a
lot of time debugging it and cursing at the computer.

SyncLock locks on a reference type. Think of it as setting a flag on
that reference type for the duration of the lock. When another thread
tries to take a lock on the same object, the runtime can see the flag
is set and force the second thread to wait for the lock to become
free.

Hope this made some sense..

--
Scott
http://www.OdeToCode.com
On Thu, 16 Sep 2004 00:19:55 +0200, "Henri" <hm********@hotmail.com>
wrote:

1) Do Shared methods always need to be synchronised to be thread-safe?
2) Why must SyncLock be used with a reference type? I can't get the relation
between threads and a type.

Thanks for your help.
Henri

[Henri]

Thanks for your explaination Scott :-) !
In Java, I was used to use an instance of a class to synchronise methods.
That's why I was a bit confused here about using a Type object instead.

About Shared methods: variables local to a method are not shared between
thread, are they.
"Scott Allen" <bitmask@[nospam].fred.net> a écrit dans le message de
news:n4********************************@4ax.com...

1) Not always. If you have any Shared fields on the type and you are
both reading and writing them, then probably. Thread safety is needed
when you are sharing data between threads.

2) Threads are an abstraction that 'execute' code. Types are an
abstraction that 'contain' code. You can have multiple threads
executing the same code inside of a type concurrently. If you have
data that can be touched by multiple threads, you have to be careful
that two threads are not changing an ArrayList, for example, at the
same time, because it leads to unpredictable behavior and you spend a
lot of time debugging it and cursing at the computer.

SyncLock locks on a reference type. Think of it as setting a flag on
that reference type for the duration of the lock. When another thread
tries to take a lock on the same object, the runtime can see the flag
is set and force the second thread to wait for the lock to become
free.

Hope this made some sense..

--
Scott
http://www.OdeToCode.com
On Thu, 16 Sep 2004 00:19:55 +0200, "Henri" <hm********@hotmail.com>
wrote:

1) Do Shared methods always need to be synchronised to be thread-safe?
2) Why must SyncLock be used with a reference type? I can't get the relationbetween threads and a type.

Thanks for your help.
Henri

[Scott Allen]

On Thu, 16 Sep 2004 01:34:06 +0200, "Henri" <hm********@hotmail.com>
wrote:

Thanks for your explaination Scott :-) !
In Java, I was used to use an instance of a class to synchronise methods.
That's why I was a bit confused here about using a Type object instead.

Aaaahhh - that kind of reference. Well, you have to SyncLock on a
reference that is visible among all the threads. In earlier .NET days
if was common practice for a Shared class to lock on the Type instance
for the class. Unfortunately, this is not a great practice.

You want to lock on a reference that is visible to all the threads
that might come into a method on your class, but you do not want to
lock on a reference that is visible to the entire application. Someone
else might decide to take that lock too - and it leads to difficult to
debug deadlock situations where you stay up all night and threaten to
set fire to the computer.

Now sometimes, you might need a lock that can be seen outside of your
class, but generally you want a private object to lock on, so you know
only your class is locking and unlocking on that reference. Make a
Shared, Private field of type Object and lock, unlock on it.

About Shared methods: variables local to a method are not shared between
thread, are they.

Correct. If the method only uses local variables and parameters, no
need to take locks.

--
Scott
http://www.OdeToCode.com