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