Threading Safety in System.Collections

[Howard Swope]

Could someone help explain thread safety issues in the System.Collections
classes? The documentation states:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Thread Safety
Public static (Shared in Visual Basic) members of this type are safe for
multithreaded operations. Instance members are not guaranteed to be
thread-safe.

A SortedList can support multiple readers concurrently, as long as the
collection is not modified. To guarantee the thread safety of the
SortedList, all operations must be done through the wrapper returned by the
Synchronized method.

Enumerating through a collection is intrinsically not a thread-safe
procedure. Even when a collection is synchronized, other threads could still
modify the collection, which causes the enumerator to throw an exception. To
guarantee thread safety during enumeration, you can either lock the
collection during the entire enumeration or catch the exceptions resulting
from changes made by other threads.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

When the documentation says public static members of this type do they mean
members of the collection class or static instances of the class?

Do public static members implement synchronization primitives to accomplish
this or is there something inherintly thread safe about the implementation
of the static nature?

What is the Synchronized() method doing to create the wrapper?

What is the nature of the SyncRoot object?

In most cases I am inheriting from a collection class. Are there issues
specific to inheritence that I should be aware of?

Thanks.

 

[Dave]

When the documentation says public static members of this type do they mean members of the collection class or static instances of

the class?

There is no such thing as static instances, so they mean "public static members". i.e. public static properties and fields. This
wording is used on most (if not all) of the class documentation in MSDN, so there may not actually be any public static members of
the interfaces or classes they are refering to.

Do public static members implement synchronization primitives to accomplish this or is there something inherintly thread safe
about the implementation of the static nature?

Static members are intrinsically thread-safe in .NET. No extra work is required for synchronized reads and writes of those members.

What is the Synchronized() method doing to create the wrapper?

The "recommended" approach for synchronizing collections as used by those framework classes that apply is to have a private class
(nested) that derives from the collection that may be synchronized and overrides those members that require synchronization. This
is usually done by locking "this" (or Synlock Me in VB) for the complete base.[Member] call of the member being synchronized.

What is the nature of the SyncRoot object?

It provides the object that the collection is using internally to synchronize those wrapped methods. As I mentioned above, in all
cases I'm aware of, this will be the instance of the collection itself.

In most cases I am inheriting from a collection class. Are there issues specific to inheritence that I should be aware of?

You may inherit from collection classes. This is why they aren't "sealed". In some cases it makes more sense to implement one of
the interfaces as opposed to deriving from one of the predefined implementations.

I don't think there are any "issues specific to inheritance" that apply only to collections.

 

[Howard Swope]

Dave:

I tried to send you email to thank you. I removed the NOSPAM- from you email
address, but it didn't go through for some reason. Anyway... thanks for the
information. It was very helpful. Life was much easier when I encapsulated
the System.Collections class and implemented ICollection and IEnumerable. I
grabbed the SyncRoot object and made the whole thing nice and thread safe.
Life is good.

When the documentation says public static members of this type do they
mean members of the collection class or static instances of the class?

There is no such thing as static instances, so they mean "public static
members". i.e. public static properties and fields. This wording is used
on most (if not all) of the class documentation in MSDN, so there may not
actually be any public static members of the interfaces or classes they
are refering to.

Do public static members implement synchronization primitives to
accomplish this or is there something inherintly thread safe about the
implementation of the static nature?

Static members are intrinsically thread-safe in .NET. No extra work is
required for synchronized reads and writes of those members.

What is the Synchronized() method doing to create the wrapper?

The "recommended" approach for synchronizing collections as used by those
framework classes that apply is to have a private class (nested) that
derives from the collection that may be synchronized and overrides those
members that require synchronization. This is usually done by locking
"this" (or Synlock Me in VB) for the complete base.[Member] call of the
member being synchronized.

What is the nature of the SyncRoot object?

It provides the object that the collection is using internally to
synchronize those wrapped methods. As I mentioned above, in all cases I'm
aware of, this will be the instance of the collection itself.

In most cases I am inheriting from a collection class. Are there issues
specific to inheritence that I should be aware of?

You may inherit from collection classes. This is why they aren't
"sealed". In some cases it makes more sense to implement one of the
interfaces as opposed to deriving from one of the predefined
implementations.

I don't think there are any "issues specific to inheritance" that apply
only to collections.

--
Dave Sexton
[email protected]
-----------------------------------------------------------------------

Could someone help explain thread safety issues in the System.Collections
classes? The documentation states:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Thread Safety
Public static (Shared in Visual Basic) members of this type are safe for
multithreaded operations. Instance members are not guaranteed to be
thread-safe.

A SortedList can support multiple readers concurrently, as long as the
collection is not modified. To guarantee the thread safety of the
SortedList, all operations must be done through the wrapper returned by
the Synchronized method.

Enumerating through a collection is intrinsically not a thread-safe
procedure. Even when a collection is synchronized, other threads could
still modify the collection, which causes the enumerator to throw an
exception. To guarantee thread safety during enumeration, you can either
lock the collection during the entire enumeration or catch the exceptions
resulting from changes made by other threads.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

When the documentation says public static members of this type do they
mean members of the collection class or static instances of the class?

Do public static members implement synchronization primitives to
accomplish this or is there something inherintly thread safe about the
implementation of the static nature?

What is the Synchronized() method doing to create the wrapper?

What is the nature of the SyncRoot object?

In most cases I am inheriting from a collection class. Are there issues
specific to inheritence that I should be aware of?

Thanks.