Lock and Synchronized

[Guest]

Some classes, like Queue and SortedList, have a Synchronized method which gives a thread safe wrapper object for these classes. But the lock() statement does the same thing. Is there any rules as to when to use one and not the other? For instance, if I wanted to remove an item in a SortedList, would it be better to lock() it or do it via the Synchronized wrapper? Why choose one over the other

SortedList sl

lock(sl

sl.Remove(item)


O

SortedList sl2 = SortedList.Synchronized(sl)
sl2.Remove(item)

Same question for iterations. Does lock() and synchronized do the same thing

lock(sl

for(int i = 0; i < sl.Count; i++




O

SortedList sl2 = SortedList.Synchronized(sl)
for(int i = 0; i < sl2.Count; i++



Thanks

Rich Sienkiewic
Dictaphone Corp

 

[Klaus H. Probst]

Synchronized? IsSynchronized is a property that returns a bool. It doesn't
return "a synchronized object". You're thinking of SyncRoot, maybe?

But anyway, the correct way is to lock on the SyncRoot object returned by
the hash/list class. Locking on the type instance itself is not recommended
and is actually unsafe.

--
____________________
Klaus H. Probst, MVP
http://www.vbbox.com/

Some classes, like Queue and SortedList, have a Synchronized method which

gives a thread safe wrapper object for these classes. But the lock()
statement does the same thing. Is there any rules as to when to use one and
not the other? For instance, if I wanted to remove an item in a SortedList,
would it be better to lock() it or do it via the Synchronized wrapper? Why
choose one over the other.

 

[Jon Skeet [C# MVP]]

Synchronized? IsSynchronized is a property that returns a bool. It doesn't
return "a synchronized object". You're thinking of SyncRoot, maybe?

No, he's thinking of Synchronized, rather than IsSynchronized.
SortedList.Synchronized, however, is a method which returns a
synchronized wrapped for the SortedList.

But anyway, the correct way is to lock on the SyncRoot object returned by
the hash/list class. Locking on the type instance itself is not recommended
and is actually unsafe.

The latter is certainly true. The former is "sort-of" true.

The synchronized wrapper make each call to the list synchronized.
However, most of the time that isn't actually enough - you typically
want to synchronize a *sequence* of operations rather than one
operation at a time.

 

[Guest]

Thanks for the reply guys. But I'm more confused. I should not lock the instance like this

lock(sl

but lock the SyncRoot, like this

lock(sl.SyncRoot

But the help system (C# Programmer's Reference) describing the lock statement says "The lock keyword marks a statement block as a critical section by obtaining the mutual-exclusion lock for a given object, executing a statement, and then releasing the lock." It never mentions the SyncRoot, just lock the instance itself.

The help system is misleading then in talking about the Synchronized method. It says, for the SortedList.Synchronized method, "Returns a synchronized (thread-safe) wrapper for the SortedList.". Then in the Remarks section it says "To guarantee the thread safety of the SortedList, all operations must be done through this wrapper only." That to me says get and use the wrapper for thread safety. If this is not true then this must be reworded, no

So my question remains, if I have one thread iterating over a SortedList and another thread can come along and add/delete an item from it, what should each thread do to the SortedList, lock or Synchronize

Thanks

Rich

 

[Eric Gunnerson [MS]]

Locking the object is fine.

If you were thinking of using:

lock(this)

You should know that because you're looking on your instance, users of your
class could also lock on it and screw you up. Whether or not that is an
issue depends on what you think your users might do. The same situation
exists if you're doing:

lock(typeof(MyClass))

If you don't want to do this, you can easily allocate a static or instance
object (ie object myLock = new object()), and then lock on that.

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://weblogs.asp.net/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.

Thanks for the reply guys. But I'm more confused. I should not lock the instance like this:

lock(sl)

but lock the SyncRoot, like this?

lock(sl.SyncRoot)

But the help system (C# Programmer's Reference) describing the lock

statement says "The lock keyword marks a statement block as a critical
section by obtaining the mutual-exclusion lock for a given object, executing
a statement, and then releasing the lock." It never mentions the SyncRoot,
just lock the instance itself.

The help system is misleading then in talking about the Synchronized

method. It says, for the SortedList.Synchronized method, "Returns a
synchronized (thread-safe) wrapper for the SortedList.". Then in the Remarks
section it says "To guarantee the thread safety of the SortedList, all
operations must be done through this wrapper only." That to me says get and
use the wrapper for thread safety. If this is not true then this must be
reworded, no?

So my question remains, if I have one thread iterating over a SortedList

and another thread can come along and add/delete an item from it, what
should each thread do to the SortedList, lock or Synchronize?