469,304 Members | 2,303 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,304 developers. It's quick & easy.

how to make List<T> thread safe?

Hi NG,

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

Thanks for hints and help!

Rainer
Jan 20 '06 #1
9 30801
.... hm.... Monitor.Enter and .Exit should do this job, right?

Regards
Rainer
Jan 20 '06 #2

"Rainer Queck" <Ra****@noemail.noemail> wrote in message
news:%2******************@TK2MSFTNGP14.phx.gbl...
... hm.... Monitor.Enter and .Exit should do this job, right?


Depends what you mean by "make it threadsafe".

What about iteration?
What about []?
Jan 20 '06 #3
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...
Rainer Queck wrote:
Hi NG,

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

Thanks for hints and help!

Rainer

Jan 20 '06 #4
> 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).

--
Venlig hilsen
Anders Borum / SphereWorks
Microsoft Certified Professional (.NET MCP)
Jan 21 '06 #5
Anders Borum <an****@sphereworks.dk> wrote:
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).


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 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
Jan 21 '06 #6
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_undocum.../04/index.html

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Anders Borum <an****@sphereworks.dk> wrote:
> 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).


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

Jan 21 '06 #7
Nicholas Paldino [.NET/C# MVP] <mv*@spam.guard.caspershouse.com> wrote:
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_undocum.../04/index.html


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

--
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
Jan 21 '06 #8
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 [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Nicholas Paldino [.NET/C# MVP] <mv*@spam.guard.caspershouse.com> wrote:
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_undocum.../04/index.html


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

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

Jan 21 '06 #9
Nicholas Paldino [.NET/C# MVP] <mv*@spam.guard.caspershouse.com> wrote:
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...

--
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
Jan 21 '06 #10

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

17 posts views Thread by Rainer Queck | last post: by
2 posts views Thread by =?Utf-8?B?Unlhbg==?= | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
reply views Thread by harlem98 | last post: by
1 post views Thread by Geralt96 | last post: by
reply views Thread by harlem98 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.