Threading Safety in System.Collections

[Howard Swope]

Could someone help explain thread safety issues in the System.Collecti ons
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.

--
Howard Swope [howardsnewsATsp itzincDOTcom]
Software Engineer
Spitz, Inc [http://www.spitzinc.com]

[Dave]

Re: Threading Safety in System.Collecti ons

> When the documentation says public static members of this type do they mean members of the collection class or static instances of[color=blue]
> the class?[/color]

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.
[color=blue]
> Do public static members implement synchronization primitives to accomplish this or is there something inherintly thread safe
> about the implementation of the static nature?[/color]

Static members are intrinsically thread-safe in .NET. No extra work is required for synchronized reads and writes of those members.
[color=blue]
> What is the Synchronized() method doing to create the wrapper?[/color]

The "recommende d" 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.
[color=blue]
> What is the nature of the SyncRoot object?[/color]

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.
[color=blue]
> In most cases I am inheriting from a collection class. Are there issues specific to inheritence that I should be aware of?[/color]

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
dave@www..jwaon line..com
-----------------------------------------------------------------------
"Howard Swope" <howardsnewsATs pitzincDOTcom> wrote in message news:eyS3LuebFH A.3280@TK2MSFTN GP09.phx.gbl...[color=blue]
> Could someone help explain thread safety issues in the System.Collecti ons 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.
>
> --
> Howard Swope [howardsnewsATsp itzincDOTcom]
> Software Engineer
> Spitz, Inc [http://www.spitzinc.com]
>
>[/color]

[Howard Swope]

Re: Threading Safety in System.Collecti ons

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.Collecti ons class and implemented ICollection and IEnumerable. I
grabbed the SyncRoot object and made the whole thing nice and thread safe.
Life is good.

"Dave" <NOSPAM-dave@dotcomdata solutions.com> wrote in message
news:u2oQ1CkbFH A.3040@TK2MSFTN GP14.phx.gbl...[color=blue][color=green]
>> When the documentation says public static members of this type do they
>> mean members of the collection class or static instances of the class?[/color]
>
> 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.
>[color=green]
>> Do public static members implement synchronization primitives to
>> accomplish this or is there something inherintly thread safe about the
>> implementation of the static nature?[/color]
>
> Static members are intrinsically thread-safe in .NET. No extra work is
> required for synchronized reads and writes of those members.
>[color=green]
>> What is the Synchronized() method doing to create the wrapper?[/color]
>
> The "recommende d" 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.
>[color=green]
>> What is the nature of the SyncRoot object?[/color]
>
> 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.
>[color=green]
>> In most cases I am inheriting from a collection class. Are there issues
>> specific to inheritence that I should be aware of?[/color]
>
> 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
> dave@www..jwaon line..com
> -----------------------------------------------------------------------
> "Howard Swope" <howardsnewsATs pitzincDOTcom> wrote in message
> news:eyS3LuebFH A.3280@TK2MSFTN GP09.phx.gbl...[color=green]
>> Could someone help explain thread safety issues in the System.Collecti ons
>> 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.
>>
>> --
>> Howard Swope [howardsnewsATsp itzincDOTcom]
>> Software Engineer
>> Spitz, Inc [http://www.spitzinc.com]
>>
>>[/color]
>
>[/color]