Thread safety of collections

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

 

[Jon Skeet [C# MVP]]

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?

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

 

[Imran Koradia]

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?

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.

 

[Guest]

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.

 

[Nic]

Thanks, that answers my question.

-----Original Message-----

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.


.

 

[Richard Blewett [DevelopMentor]]

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

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?

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]

 

[Imran Koradia]

That's a good point..

Imran.

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

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?

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]

 

[Jon Skeet [C# MVP]]

The collections are set up beforehand so I shouldn't need
volatile writes (a read following a write is already
guaranteed in a collection)

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.

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.

I think the chances that it's unsafe are very, very small, to be
honest.

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.

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