lock(obj) vs SyncRoot? 
Author Message
 lock(obj) vs SyncRoot?

When SyncRoot is missing on a class, is it safe to issue lock(obj) or must I
use a separate mutex? In my specific case, I need to synchronize a single
Socket instance between threads.

Why is SyncRoot required on some but not all objects? Are they using
internal thread somehow?

Best regards,

Dag Christensen



Sat, 28 May 2005 17:25:04 GMT  
 lock(obj) vs SyncRoot?

Quote:
> When SyncRoot is missing on a class, is it safe to issue lock(obj) or must
I
> use a separate mutex? In my specific case, I need to synchronize a single
> Socket instance between threads.

It will be safe if all parties will also use the lock on the same object.

Quote:
> Why is SyncRoot required on some but not all objects? Are they using
> internal thread somehow?

They generaly use locks.
--
Nesterovsky Vladimir



Sat, 28 May 2005 17:46:25 GMT  
 lock(obj) vs SyncRoot?


Quote:
> When SyncRoot is missing on a class, is it safe to issue lock(obj) or must
I
> use a separate mutex? In my specific case, I need to synchronize a single
> Socket instance between threads.

> Why is SyncRoot required on some but not all objects? Are they using
> internal thread somehow?

SyncRoots are provided by collections so that the collection as a whole can
be locked in the same way - using the same object - by Framework threads and
3rd-party coded threads.

Quote:

> Best regards,

> Dag Christensen

--
MikeB


Sun, 29 May 2005 04:12:57 GMT  
 lock(obj) vs SyncRoot?

Quote:
> SyncRoots are provided by collections so that the collection as a whole
can
> be locked in the same way - using the same object - by Framework threads
and
> 3rd-party coded threads.

Do you mean the collection object itself and all objects it contains? I
still don't see why you simply can't lock (myhashtable) - this should block
access to the indexer and other member functions. Does collections contain
shared/static members that must be locked in addition to the instance
itself?

I've read the documentation on SyncRoot / Synchronized, but it doesn't
clearify (for me at least:-) why I must use them instead of lock (obj).

Dag



Sun, 29 May 2005 17:12:23 GMT  
 lock(obj) vs SyncRoot?

Quote:
> Do you mean the collection object itself and all objects it contains? I
> still don't see why you simply can't lock (myhashtable) - this should
block
> access to the indexer and other member functions. Does collections contain
> shared/static members that must be locked in addition to the instance
> itself?

> I've read the documentation on SyncRoot / Synchronized, but it doesn't
> clearify (for me at least:-) why I must use them instead of lock (obj).

It is potentially possible that they use some more efficient method for
syncronization (readonly or not resizable collections are syncronized by
default).

From the other side collections usually are locking sync root object, but
not themselves.
Locking sync wrapper itself does not prevent from change of the root
collection.

Just look at source.
--
Nesterovsky Vladimir



Sun, 29 May 2005 20:16:50 GMT  
 lock(obj) vs SyncRoot?


Quote:
> > SyncRoots are provided by collections so that the collection as a whole
> can
> > be locked in the same way - using the same object - by Framework threads
> and
> > 3rd-party coded threads.

> Do you mean the collection object itself and all objects it contains? I
> still don't see why you simply can't lock (myhashtable) - this should
block
> access to the indexer and other member functions. Does collections contain
> shared/static members that must be locked in addition to the instance
> itself?

> I've read the documentation on SyncRoot / Synchronized, but it doesn't
> clearify (for me at least:-) why I must use them instead of lock (obj).

The documentation for ICollection.SyncRoot might make things a bit clearer
on the reason for SyncRoot - note that it indicates that the expected
implementation of the SyncRoot property for most collections (whose
underlying store is not publicly available) is to simply return the current
instance.  So in these cases, lock( myCollection.SyncRoot) and
lock(myCollection) will be equivalent.

Having the SyncRoot property allows the underlying store of a collection to
be wrapped by other classes, but still be synchronizable.

A (possibly bad) example is that you might have a Stack collection that's
implemented  with a LinkedList collection internally.  Suppose the Stack
class has a property that returns a reference to the underlying LinkedList
object (for whatever reason).  in this case separate threads which
lock(myStack) and lock(myLinkedList) would not block each other.

In this case, the myStack.SyncRoot property should return a reference to
myStack.stacksLinkedList.SyncRoot so that lock(myStack.SyncRoot) and
lock(myLinkedList.SyncRoot) would be locking the same object.

--
MikeB



Mon, 30 May 2005 02:36:02 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. Obj A references Obj B which in turn references Obj A

2. .lib vs .obj

3. num lock, cap lock, and scroll lock

4. multiple .OBJ's vs. #includes

5. InternetExplorer Obj vs HTML Control

6. Deployment tool crashes VS.NET if you add a .obj file

7. Caps Lock / Num Lock / Scroll Lock

8. C#: What is 'SyncRoot'

9. HELP: Linking 16-bit obj-modules and 32-bit obj-modules together

10. mod-obj.obj

11. VS.NET locks after VSS access?

12. VS toolbox locked in .NET mode

 

 
Powered by phpBB® Forum Software