Hi,

Although enumeration isn't thread-safe, you can use it's SyncRoot as shown
below.  The alternative is as mentioned in Effective Java, lock briefly,
make a defensive copy of the collection, then enumerate.  This would
obviously depend on the number of items involved, as to which solution is
good for you.

When enumerating a collection you should use a lock on the collections'
SyncRoot

 The following code example shows how to lock the collection using the
SyncRoot during the entire enumeration:
[C#]
Queue myCollection = new Queue();
 lock( myCollection.SyncRoot ) {
 foreach ( Object item in myCollection ) {
 // Insert your code here.
 }
}
ms-help://MS.NETFrameworkSDK/cpref/html/frlrfSystemCollectionsQueueClassSync
hronizedTopic.htm

Hope this is of some help,

Duncan
----- Original Message -----
From: "Tracy Martin" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, April 15, 2002 5:06 PM
Subject: Re: [DOTNET] Threading and Enumeration


> Thanks... (Somehow I always seem to miss the documents I need to see
> when I'm searching...)
>
> > -----Original Message-----
> > From: dotnet discussion
> > [mailto:[EMAIL PROTECTED]]On Behalf Of
> > Ethan Smith
> > Sent: Monday, April 15, 2002 11:40
> > To: [EMAIL PROTECTED]
> > Subject: Re: Threading and Enumeration
> >
> >
> > From the docs:
> >
> > "An enumerator remains valid as long as the collection remains
> > unchanged. If changes are made to the collection, such as adding,
> > modifying or deleting elements, the enumerator is irrecoverably
> > invalidated and the next call to MoveNext or Reset throws an
> > InvalidOperationException. If the collection is modified between
> > MoveNext and Current, Current will return the element that
> > it is set to,
> > even if the enumerator is already invalidated.
> >
> > The enumerator does not have exclusive access to the collection;
> > therefore, 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."
> >
> >
> > <Ms-help://MS.VSCC/MS.MSDNVS/cpref/html/frlrfsystemcollectio
> > nsienumerato
> > rclasstopic.htm>
> >
> > -----Original Message-----
> > From: dotnet discussion [mailto:[EMAIL PROTECTED]]
> > On Behalf Of
> > Tracy Martin
> > Sent: Monday, April 15, 2002 11:33 AM
> > To: [EMAIL PROTECTED]
> > Subject: [DOTNET] Threading and Enumeration
> >
> > Greetings,
> >
> > Does anyone have any information about how enumerators
> > handle changes
> > in the object during enumeration? Or, more specifically, I have a
> > scenario where I have a collection of objects that potentially being
> > added to by separate threads while being enumerated on
> > another thread.
> > Only one thread would be adding objects at a time (and
> > adding would be
> > synchronized to ensure that only one add operation is happening at a
> > time), but my question revolved around - would the
> > enumerating thread
> > find the newly added objects, or would it be necessary to
> > account for
> > this (by resetting the enumeration after an add, or some
> > other method
> > of notifying the enumerating thread that the underlying
> > collection has
> > changed)?
> >
> > Tracy
> >
> > You can read messages from the DOTNET archive, unsubscribe
> > from DOTNET,
> > or
> > subscribe to other DevelopMentor lists at
> http://discuss.develop.com.
>
> You can read messages from the DOTNET archive, unsubscribe from
> DOTNET, or
> subscribe to other DevelopMentor lists at http://discuss.develop.com.
>
> You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
> subscribe to other DevelopMentor lists at http://discuss.develop.com.

You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.

Reply via email to