471,056 Members | 1,514 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,056 software developers and data experts.

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

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) ?

Aug 9 '06 #1
7 5968
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 ReaderWriterLock. 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.

Aug 9 '06 #2

"bonk" <sc******************@gmx.dewrote in message
news:11**********************@m79g2000cwm.googlegr oups.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.

ReaderWriterLock 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
Aug 9 '06 #3
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" <davidbaxterbrowne no potted me**@hotmail.comschrieb im
Newsbeitrag news:Oz**************@TK2MSFTNGP03.phx.gbl...
>
"bonk" <sc******************@gmx.dewrote in message
news:11**********************@m79g2000cwm.googlegr oups.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.

ReaderWriterLock 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

Aug 9 '06 #4

"bonk" <bi*****@msn.comwrote in message
news:OG****************@TK2MSFTNGP04.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
Aug 9 '06 #5
bonk <bi*****@msn.comwrote:
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.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Aug 9 '06 #6
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?
Aug 10 '06 #7
<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.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Aug 10 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

12 posts views Thread by Brett Romero | last post: by
2 posts views Thread by Shimon Sim | last post: by
10 posts views Thread by Chris Mullins [MVP] | last post: by
44 posts views Thread by Zytan | last post: by
4 posts views Thread by Peter K | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.