Search:   Namespaces Discussions .NET v1.1 Feedback

Thread safety of collections Messages   Related Types This message was discovered on microsoft.public.dotnet.framework. Responses highlighted in red are from those people who are likely to be able to contribute good, authoratitive information to this discussion. They include Microsoft employees, MVP's and others who IMHO contribute well to these kinds of discussions. Post a new message to this list... Nic The documentation for most collection classes state that public static members are thread safe, but to what extent can a collection be accessed safely via multiple threads calling non static methods if the collection is not changed (written) by any other thread? E.g. when using either a Hashtable or an ArrayList with fixed contents (not changed during the test), I seem to be able to safely read from them via multiple threads without any synchronisation. Given a collection with fixed contents, are multiple readers thread safe even though the read operations call non static methods? Thanks for any help Nic. Reply to this message...        Jon Skeet [C# MVP] (VIP) Nic <Click here to reveal e-mail address> wrote: [Original message clipped] I suspect that for true honest-to-goodness thread safety you should make sure that there's a volatile write in whatever thread sets up the collections to start with, and then a volatile read in the reading threads, but thereafter you should be fine. In practice, you're unlikely to have to make sure you do the volatile write/read. I can't envisage it actually being necessary in the near future, even though in theory it just might be. (You don't need a volatile read every time you're going to read - just once, after the volatile write.) -- Jon Skeet - <Click here to reveal e-mail address> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Reply to this message...        anonymous@discussions.microsoft.com The collections are set up beforehand so I shouldn't need volatile writes (a read following a write is already guaranteed in a collection), but I then have a loop where multiple threads iterate the same collection(s). While this is happening the collections are NOT changed, so as long as this is safe I'll be fine. But since non-static methods are not explicitly stated to be thread safe, does this not perhaps mean that a future version of .NET could break the code (multiple non- synchronised readers)? I can't find anything in the docs which states that multiple readers are safe as long as the collection isn't modified. Reply to this message...        Jon Skeet [C# MVP] (VIP) <Click here to reveal e-mail address> wrote: [Original message clipped] Hmm... I wonder quite how well it's guaranteed, to be honest. When most people think of thread safety they don't really think about volatility. The same could be true for the collections - or the implementation may be threadsafe on the current CLR, but isn't guaranteed to be on *all* conformant CLRs. [Original message clipped] I think the chances that it's unsafe are very, very small, to be honest. [Original message clipped] Well, ArrayList has: <quote> An ArrayList can support multiple readers concurrently, as long as the collection is not modified. </quote> I *thought* Hashtable specified that it was okay to have multiple readers and a single writer, but I can't find that now... -- Jon Skeet - <Click here to reveal e-mail address> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Reply to this message...        Imran Koradia (VIP) [Original message clipped] I believe that is correct. I think thread safety becomes an issue only when there is modification of data involved since in that case, if you do not synchronize the operations, different threads could see different versions of the same data. Imran. Reply to this message...        Richard Blewett [DevelopMentor] (VIP) I'll mention one thing here - be very careful to ascertain what makes up a read operation. On one project I was involved with we made the (as it turned out mistaken) assumption that the DataTable.Select method was readonly. It was only when we were trying to debug some very strange threading problems that it dawned on us that it wasn't and it turned out it updated a bunch of cache information. I'm not saying that iterating through a collection is a write operation, just be careful not to assume something is readonly just because the method name(s) would suggest it. Regards Richard Blewett - DevelopMentor http://staff.develop.com/richardb/weblog nntp://news.microsoft.com/microsoft.public.dotnet.framework/<Click here to reveal e-mail address> [Original message clipped] I believe that is correct. I think thread safety becomes an issue only when there is modification of data involved since in that case, if you do not synchronize the operations, different threads could see different versions of the same data. Imran. --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.760 / Virus Database: 509 - Release Date: 10/09/2004 [microsoft.public.dotnet.framework] Reply to this message...        Imran Koradia (VIP) That's a good point.. Imran. "Richard Blewett [DevelopMentor]" <Click here to reveal e-mail address> wrote in message news:%23$Click here to reveal e-mail address... > I'll mention one thing here - be very careful to ascertain what makes up a read operation. On one project I was involved with we made the (as it turned out mistaken) assumption that the DataTable.Select method was readonly. It was only when we were trying to debug some very strange threading problems that it dawned on us that it wasn't and it turned out it updated a bunch of cache information. [Original message clipped] name(s) would suggest it. [Original message clipped] Reply to this message...        Nic Thanks, that answers my question. [Original message clipped] Reply to this message...     System.Collections.ArrayList System.Data.DataTable Ad MBR BootFX Best-of-breed application framework for .NET projects, developed by Matthew Baxter-Reynolds and MBR IT

Copyright © Matthew Baxter-Reynolds 2001-2008. '.NET 247 Software Development Services' is a trading style of MBR IT Solutions Ltd. Contact Us - Terms of Use - Privacy Policy - www.dotnet247.com