how to make List<T> thread safe?

[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]

.... hm.... Monitor.Enter and .Exit should do this job, right?

Regards
Rainer

 

[Nick Hounsome]

... hm.... Monitor.Enter and .Exit should do this job, right?

Depends what you mean by "make it threadsafe".

What about iteration?
What about []?

 

[John Murray]

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

 

[Anders Borum]

Also, I prefer to use the ReaderWriterLock for locking in lists because it

will allow multiple reads without blocking...

Although it is slower .. (atleast to my understanding and performance
tests).

 

[Jon Skeet [C# MVP]]

Although it is slower .. (atleast to my understanding and performance
tests).

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.

 

[Nicholas Paldino [.NET/C# MVP]]

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

 

[Jon Skeet [C# MVP]]

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

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

Interesting. Shame about the "only for use on Windows" bit

 

[Nicholas Paldino [.NET/C# MVP]]

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.

 

[Jon Skeet [C# MVP]]

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.

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