Synchronized Collection<T> Recommendation

[Christoph Nahr]

That IMO, is a reason why they removed it. Normally a collection writer
using containment will already have a syncroot object for the class -
exposed or not. And use that object to sync all invariants in the
collection (maybe even abstracting multiple collections). So the SyncRoot
Property in the contained collections are never used and become "overhead"
in the API. If there is no sync wrapper using it, there is no need for a
SyncRoot property.

But what if the client wants to manually synchronize access to a
specific collection? Wouldn't you say that SyncRoot is useful for
that purpose?

 

[Lucian Wischik]

Synchronized wrapper ("oh, the docs say it's thread-safe!"), then do a

The phrase "thread-safe" bugs me. I think it's ambiguous and therefore
meaningless. Every single instance of the phrase should be erased and
replaced with the actual precise description of what it means -- i.e.
which invariants it preserves, in the face of which other concurrent
actions.

 

[William Stacey [MVP]]

| But what if the client wants to manually synchronize access to a
| specific collection? Wouldn't you say that SyncRoot is useful for
| that purpose?

Well, it may save another line in your class like "private readonly object
syncRoot2 = new object();", but that is really all it saves. So, IMO, it is
not that useful.

 

[Christoph Nahr]

The phrase "thread-safe" bugs me. I think it's ambiguous and therefore
meaningless. Every single instance of the phrase should be erased and
replaced with the actual precise description of what it means -- i.e.
which invariants it preserves, in the face of which other concurrent
actions.

I think most of the MSDN Library should be erased and replaced with a
precise description of what those classes and methods do! Usually I
have to use Reflector to figure out exactly what's going on...

But I generally understand "thread-safe" to mean "this particular
method invocation does not corrupt the internal state of the instance
or type object when performed by multiple threads simultaneously".

That's a very weak guarantee, to be sure, and usually not very useful,
since you rarely care only about the internal state of a single object
across a single method invocation. But that's realistically the best
you can do for isolated library methods.

 

[Lucian Wischik]

But I generally understand "thread-safe" to mean "this particular
method invocation does not corrupt the internal state of the instance
or type object when performed by multiple threads simultaneously".
That's a very weak guarantee, to be sure, and usually not very useful,

Yeah. What would be useful is "... when this OR OTHER METHOD OF THE
OBJECT are performed by multiple threads simultaneously".

 

[Nick Hounsome]

Yeah. What would be useful is "... when this OR OTHER METHOD OF THE
OBJECT are performed by multiple threads simultaneously".

That is what you would normally mean by saying that a whole class is
thread-safe.

Of course it is terrible design to have a class with some thread-safe
methods that is not thread-safe.

The use of the term thread-safe in discussing stuff like:
for(int i = 0; i < c.Length; ++i) foo(c);
Is wrong. This IS thread-safe.

It is also probably not going to do the right thing but that doesn't make it
"unsafe". If you had a collection that didn't support removal/truncation
then you might even be able to contrive an example of foo for which this was
an appropriate or at least acceptable algorithm.

[A similar misuse of terms applies when people start talking about object
leaks in .NET - They are simply not possible. The object can be
inappropriately held or not directly accesible to a particular piece of code
but it can never be leaked according to the normal meaning of the word]

 

[Chris Nahr]

Yeah. What would be useful is "... when this OR OTHER METHOD OF THE
OBJECT are performed by multiple threads simultaneously".

That's only an issue when multiple fields or other resources are
present, though, and if those multiple resources must be kept in a
specific relationship for the object state to be valid. If that's the
case I would assume that "thread-safe" methods would lock down all of
those resources before modifying any of them, so I think the
simultaneous execution of different methods shouldn't matter.

 

[Michael Primeaux]

I have benchmarked RWL and Monitor in the load testing of a caching API (at
the time under .NET 1.1). Under a high load, the caching API using RWL
resulted in a much higher concurrency rate than did the API using Monitor.
Granted, the application's data access pattern favored a much higher read
frequency than write frequency and used a reactive cache loading model.
Nevertheless, I was quite satisfied with the RWL.

 

[Michael Primeaux]

Great article. Thanks for the link.