Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Safe to get Count value from generic collection without locking the collection?

I have two threads, a producer thread that places objects into a generic List collection and a consumer thread that pulls those objects out of the same generic List. I've got the reads and writes to the collection properly synchronized using the lock keyword, and everything is working fine.

What I want to know is if it is ok to access the Count property without first locking the collection.

JaredPar refers to the Count property in his blog as a decision procedure that can lead to race conditions, like this:

if (list.Count > 0)
{
    return list[0];
}

If the list has one item and that item is removed after the Count property is accessed but before the indexer, an exception will occur. I get that.

But would it be ok to use the Count property to, say, determine the initial size a completely different collection? The MSDN documentation says that instance members are not guaranteed to be thread safe, so should I just lock the collection before accessing the Count property?

like image 230
Matt Davis Avatar asked Aug 29 '09 21:08

Matt Davis


People also ask

Is list count thread safe?

For an inherently thread–safe alternative, see the ImmutableList class. Because . Count is an instance member, according to the above, it is not thread safe.

Is generic list thread safe?

It is a thread-safe variant of ArrayList. T represents generic.

Is .NET Dictionary thread safe if not explain?

No, they are not thread safe (without performing your own locking). Use one of the Concurrent collections instead. The System.

How do you make a class thread safe in C#?

Lock provides the thread safety in multi-threaded application in C# . The lock keyword specified only one thread can be executed on at a time. when we use lock thread then only those line of code executed which is given in the scope of lock for specific thread.


1 Answers

I suspect it's "safe" in terms of "it's not going to cause anything to go catastrophically wrong" - but that you may get stale data. That's because I suspect it's just held in a simple variable, and that that's likely to be the case in the future. That's not the same as a guarantee though.

Personally I'd keep it simple: if you're accessing shared mutable data, only do so in a lock (using the same lock for the same data). Lock-free programming is all very well if you've got appropriate isolation in place (so you know you've got appropriate memory barriers, and you know that you'll never be modifying it in one thread while you're reading from it in another) but it sounds like that isn't the case here.

The good news is that acquiring an uncontested lock is incredibly cheap - so I'd go for the safe route if I were you. Threading is hard enough without introducing race conditions which are likely to give no significant performance benefit but at the cost of rare and unreproducible bugs.

like image 73
Jon Skeet Avatar answered Sep 18 '22 08:09

Jon Skeet