how to make List<T> thread safe?

  • Thread starter Thread starter Rainer Queck
  • Start date Start date
R

Rainer Queck

Hi NG,

what would be the easiest way to make a generic list thread safe?

Thanks for hints and help!

Rainer
 
Rainer Queck said:
... hm.... Monitor.Enter and .Exit should do this job, right?
Click to expand...

Depends what you mean by "make it threadsafe".

What about iteration?
What about []?
 
The easiest way would be to lock the instance of the generic list before
any accesses to it. This is certainly not the most performant, or the
safest ...

IMHO, The safest (from a development perspective) is to implement a
custom, generic list that encapsulates one of the standard generic lists
and includes the locking in the exposed methods. This removes the
possibility that some future developer could forget to do the locking.
Also, I prefer to use the ReaderWriterLock for locking in lists because
it will allow multiple reads without blocking...
 
Also, I prefer to use the ReaderWriterLock for locking in lists because it
will allow multiple reads without blocking...
Click to expand...

Although it is slower .. (atleast to my understanding and performance
tests).
 
Anders Borum said:
Although it is slower .. (atleast to my understanding and performance
tests).
Click to expand...

It will be slower than locking if the lock never ends up being
contested, but if you have a lot of readers and very few writers,
ReaderWriterLock is likely to end up winning - especially if the
readers spend a significant amount of time in the lock.
 
Jon,

While yes, in practice this ^should^ be true, it is not. There is a
problem with the current implementation of ReaderWriterLock in that the
performance is horrible (I personally have tested it and in areas of high
contention, found that it is 6-7 times slower than using Monitor/lock).

Apparently, Jeffery Richter (from Wintellect) has addressed this in his
own implementation of ReaderWriterLock, which he patented, and subsequently
sold to MS. There is a description here:

http://wesnerm.blogs.com/net_undocumented/2005/04/index.html
 
Nicholas Paldino said:
While yes, in practice this ^should^ be true, it is not. There is a
problem with the current implementation of ReaderWriterLock in that the
performance is horrible (I personally have tested it and in areas of high
contention, found that it is 6-7 times slower than using Monitor/lock).
Click to expand...

I'm sure it's slower in terms of acquisition, but surely the point of
ReaderWriterLock is that more threads can do work at the same time, so
long as they won't interfere with each other. I would have thought that
however bad the performance of it is, there are situations in which
it's worth using.

(It's a shame it's so bad though - I've never had cause to use it
myself.)
Apparently, Jeffery Richter (from Wintellect) has addressed this in his
own implementation of ReaderWriterLock, which he patented, and subsequently
sold to MS. There is a description here:

http://wesnerm.blogs.com/net_undocumented/2005/04/index.html
Click to expand...

Interesting. Shame about the "only for use on Windows" bit :(
 
Jon,

I tried a number of situations, with 10 and 100 threads each working
concurrently, weighing the operations (read/write) in a balanced way, vs
more reads vs more writes.

It's horrendously slow EVERY time.
 
Nicholas Paldino said:
I tried a number of situations, with 10 and 100 threads each working
concurrently, weighing the operations (read/write) in a balanced way, vs
more reads vs more writes.

It's horrendously slow EVERY time.
Click to expand...

Interesting - I must give that a try some time then. As I say, it's not
something I've used anyway - I suspect that people may sometimes use it
when a simple exclusive lock would be fine anyway...
 
Back
Top