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

  • Thread starter Thread starter bonk
  • Start date Start date
B

bonk

Hello I am acessing a Dictionary<TKey,TValue> from 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) ?
 
bonk said:
Hello I am acessing a Dictionary<TKey,TValue> from 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) ?
Click to expand...

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.
 
bonk said:
Hello I am acessing a Dictionary<TKey,TValue> from 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?
Click to expand...

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) ?
Click to expand...

Read these for read/write locks in .NET.

ReaderWriterLock Class
http://msdn2.microsoft.com/en-us/library/system.threading.readerwriterlock.aspx

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

David
 
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?
 
bonk said:
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?
Click to expand...

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


David
 
bonk said:
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?
Click to expand...

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?
 
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.
 
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.
Click to expand...

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.
 
Back
Top