threading: acessing a Dictionary<TKey ,TValue> with foreach

[bonk]

Hello I am acessing a Dictionary<TKey ,TValuefrom multiple threads and
often in a foreach loop. While I am within one of the foreach loops the
other threads must not modify the collection itself since that would
cause an exception in the foreach loop "foreach can not continue
because the colelction was modifed". Now what is the least expensive
and threadsafe way to make sure that no other threads modifies that
collection. Since one of the threads will do a foreach over the
collection once every 2seconds I fear doing a complete lock
(mycollection){ } on the collection. Sinc I was told that this is
expensive. As far as I can see, all I need is a lock for writing, other
threads still may READ the data of the collection. Or are there any
sideeffects I might not be aware of yet? What is the best practise
here? How do I aquire a writeonly lock (in case this is the best
solution) ?

[sean.j.forbes]

bonk wrote:

Hello I am acessing a Dictionary<TKey ,TValuefrom multiple threads and
often in a foreach loop. While I am within one of the foreach loops the
other threads must not modify the collection itself since that would
cause an exception in the foreach loop "foreach can not continue
because the colelction was modifed". Now what is the least expensive
and threadsafe way to make sure that no other threads modifies that
collection. Since one of the threads will do a foreach over the
collection once every 2seconds I fear doing a complete lock
(mycollection){ } on the collection. Sinc I was told that this is
expensive. As far as I can see, all I need is a lock for writing, other
threads still may READ the data of the collection. Or are there any
sideeffects I might not be aware of yet? What is the best practise
here? How do I aquire a writeonly lock (in case this is the best
solution) ?

You could use a ReaderWriterLoc k. Another option, if there is only one
writer, but multiple readers, is that the writer could clone the
dictionary, update the clone, then replace the volatile reference to
the original dictionary with the updated dictionary. The readers would
need to obtain a local reference (by copying the volatile reference) to
the dictionary before reading, so that the reference isn't switched on
the reader in the middle of reading operations.

[David Browne]

"bonk" <sc************ ******@gmx.dewr ote in message
news:11******** **************@ m79g2000cwm.goo glegroups.com.. .

Hello I am acessing a Dictionary<TKey ,TValuefrom multiple threads and
often in a foreach loop. While I am within one of the foreach loops the
other threads must not modify the collection itself since that would
cause an exception in the foreach loop "foreach can not continue
because the colelction was modifed". Now what is the least expensive
and threadsafe way to make sure that no other threads modifies that
collection. Since one of the threads will do a foreach over the
collection once every 2seconds I fear doing a complete lock
(mycollection){ } on the collection. Sinc I was told that this is
expensive. As far as I can see, all I need is a lock for writing, other
threads still may READ the data of the collection. Or are there any
sideeffects I might not be aware of yet? What is the best practise
here?

First get a realistic estimate of the amount of lock waiting caused by a
simple exclusive locking scheme. If a thread iterates the collection every
2 seconds, and takes 10ms to iterate the collection, the collection would be
unavilable for writing 0.5% of the time. So do you really care enough to
implement a different locking scheme?

>How do I aquire a writeonly lock (in case this is the best
solution) ?

Read these for read/write locks in .NET.

ReaderWriterLoc k Class
http://msdn2.microsoft.com/en-us/lib...riterlock.aspx

Reader/Writer Locks and the ResourceLock Library - Jeffrey Richter
http://msdn.microsoft.com/msdnmag/is...s/default.aspx

David

[bonk]

Well, its not just the availability of the locked object that needs to be
taken into account. If was told that dock a lock on an object is expensive
in general. Isn't that so?
"David Browne" <davidbaxterbro wne no potted me**@hotmail.co mschrieb im
Newsbeitrag news:Oz******** ******@TK2MSFTN GP03.phx.gbl...

>
"bonk" <sc************ ******@gmx.dewr ote in message
news:11******** **************@ m79g2000cwm.goo glegroups.com.. .

>Hello I am acessing a Dictionary<TKey ,TValuefrom multiple threads and
often in a foreach loop. While I am within one of the foreach loops the
other threads must not modify the collection itself since that would
cause an exception in the foreach loop "foreach can not continue
because the colelction was modifed". Now what is the least expensive
and threadsafe way to make sure that no other threads modifies that
collection. Since one of the threads will do a foreach over the
collection once every 2seconds I fear doing a complete lock
(mycollection) {} on the collection. Sinc I was told that this is
expensive. As far as I can see, all I need is a lock for writing, other
threads still may READ the data of the collection. Or are there any
sideeffects I might not be aware of yet? What is the best practise
here?

First get a realistic estimate of the amount of lock waiting caused by a
simple exclusive locking scheme. If a thread iterates the collection
every 2 seconds, and takes 10ms to iterate the collection, the collection
would be unavilable for writing 0.5% of the time. So do you really care
enough to implement a different locking scheme?

>>How do I aquire a writeonly lock (in case this is the best
solution) ?

Read these for read/write locks in .NET.

ReaderWriterLoc k Class
http://msdn2.microsoft.com/en-us/lib...riterlock.aspx

Reader/Writer Locks and the ResourceLock Library - Jeffrey Richter
http://msdn.microsoft.com/msdnmag/is...s/default.aspx

David

[David Browne]

"bonk" <bi*****@msn.co mwrote in message
news:OG******** ********@TK2MSF TNGP04.phx.gbl. ..

Well, its not just the availability of the locked object that needs to be
taken into account. If was told that dock a lock on an object is expensive
in general. Isn't that so?

No. Locking objects using Monitor or lock() is not expensive.
David

[Jon Skeet [C# MVP]]

bonk <bi*****@msn.co mwrote:

Well, its not just the availability of the locked object that needs to be
taken into account. If was told that dock a lock on an object is expensive
in general. Isn't that so?

No. Uncontested locks are staggeringly cheap. While developing an
"improved" lock I measured the performance - I could acquire and
release a lock 22 million times in a second. Doing that once every two
seconds will give you a 0.000002% performance penalty. I would suggest
that that's not likely to be significant.
I suspect whoever told you that locks are expensive also advocates
using status codes as return values instead of throwing exceptions on
error, right?

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[sean.j.forbes]

Well, multithreaded code is usually very expensive to maintain,
especially when there is a lot of state shared between a lot of
threads. Locks are more expensive to human comprehension than to CPUs.
Like threads, locks are often overused, and misused, because simpler
solutions usually exist.

bonk wrote:

Well, its not just the availability of the locked object that needs to be
taken into account. If was told that dock a lock on an object is expensive
in general. Isn't that so?

[Jon Skeet [C# MVP]]

<se***********@ gmail.comwrote:

Well, multithreaded code is usually very expensive to maintain,
especially when there is a lot of state shared between a lot of
threads. Locks are more expensive to human comprehension than to CPUs.
Like threads, locks are often overused, and misused, because simpler
solutions usually exist.

On the other hand, if threading *does* need to be involved, using a
simple lock is often the easiest solution to sharing data in a thread-
safe way.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too