Am I thread safe yet?

Reading the MSDN documentation on the Synchronized property on the Queue object I was left confused when reading the description. When working with queues and accessing them from multiple threads should I rely on the wrapped queue returned from the Synchronised method:

To guarantee the thread safety of the Queue, all operations must be done through the wrapper returned by the Synchronized method.

or should I play it safe and do lock the queue myself:

Enumerating through a collection is intrinsically not a thread-safe procedure. Even when a collection is synchronized, other threads can 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.

After discussing this and reading a few posts on the subject it seems that the confusion is around what an operation is in the first quote. It would seem that if I called the dequeue method (read operation) on the Queue object that by default it is not thread safe. Calling the dequeuemethond through the wrapper returned by the synchronized method is thread safe.

So the next scenario is where you want two (2) or more calls on a queue to be thread safe as per the example for the syncrootproperty on MSDN. Here you need to manually lock the object in question.

 SyncLock myCollection.SyncRoot
  For Each item In myCollection
  ' Insert your code here.
  Next item
 End SyncLock



2 Responses to “Am I thread safe yet?”

  1. Karl Hulme Says:

    Hi there, nice post. I recently had to write a synchronised collection class, so it shows how the SyncRoot property is used with the lock statement internally and might shed some more light on why operations such as For Each might need be synchronized independently. I’ve based it on the implementation of the synchronization classes provided with the framework as exposed by Roeders Reflector tool.

    You also pointed out that MS suggests 2 ways to guarantee thread safety, the first to do a manual lock as you’ve shown and the second was simply to catch the errors thrown by the IEnumerator. Surprisingly, Windows Presentation Foundation must do the later because it never queries the ICollection.IsSynchronized or ICollection.SyncRoot properties.

    As a thought – do you think that an implementation of IEnumerator could be devised that automatically locks and unlocks the collection on Reset( ) and the last call to MoveNext( )…?

  2. Karl Hulme Says:

    D’oh. I forgot to include the link as always:

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: