54

let's say I have the following code:

ConcurrentDictionary<long, long> myDict= new ConcurrentDictionary<long, long>();

Normally every access by key is threadsafe, but is also the following linq query threadsafe? I have not found anything in the docs: http://msdn.microsoft.com/en-us/library/dd287226.aspx

if myDict.Values.Any(x => !x.HasPaid))
{
  return false
}
Chris
  • 4,325
  • 11
  • 51
  • 70

4 Answers4

50

Correction... I'm not sure when you are accessing the Values property. It is thread safe when using LINQ on the object itself.

LINQ will use the GetEnumerator method to itterate the items.

Straight from MSDN

The enumerator returned from the dictionary is safe to use concurrently with reads and writes to the dictionary, however it does not represent a moment-in-time snapshot of the dictionary. The contents exposed through the enumerator may contain modifications made to the dictionary after GetEnumerator was called

if myDict.Any(x => !x.Value.HasPaid))
{
  return false
}
Judah Gabriel Himango
  • 58,906
  • 38
  • 158
  • 212
chilltemp
  • 8,854
  • 8
  • 41
  • 46
49

As already mentioned, ConcurrentDictionary<TKey, TValue>.GetEnumerator() does not represent a moment-in-time snapshot of the dictionary. However, ConcurrentDictionary<TKey, TValue>.Values does produce a moment-in-time snapshot.

Therefore the following are not equivalent:

myDict.Any(x => !x.Value.HasPaid)
myDict.Values.Any(x => !x.HasPaid)
Andre Kampling
  • 5,476
  • 2
  • 20
  • 47
Kevin
  • 965
  • 6
  • 12
  • 1
    Interesting, do you have a source for this? Documentation of .Values does not specifically mention it is a snapshot: http://msdn.microsoft.com/en-us/library/dd381929.aspx – Alexander Abramov Apr 03 '13 at 09:25
  • 12
    The documentation isn't clear except that it returns a collection vs. an enumerable. But take a look at the source code: the Values getter calls GetValues() which acquires lock, constructs and populates a new list, and releases lock. – Kevin Apr 03 '13 at 20:23
  • 3
    Ah thank you, I didn't look at the source code myself. Of course if this is not documented this is an implementation detail subject to change, but still interesting to know. – Alexander Abramov Apr 04 '13 at 14:58
14

The documentation of the ConcurrentDictionary states (MSDN):

All public and protected members of ConcurrentDictionary are thread-safe and may be used concurrently from multiple threads.

Since the .Values property is an implementation dictated by the IColletion interface it is public and therefore thread safe.

Shay
  • 1,680
  • 2
  • 26
  • 39
Jan C. de Graaf
  • 171
  • 1
  • 6
  • 3
    It is thread safe, but acquires a lock leading to possible deadlocks. Same goes for Count, Keys, and IsEmpty: http://geekswithblogs.net/simonc/archive/2012/02/22/inside-the-concurrent-collections-concurrentdictionary.aspx – DuneCat May 16 '13 at 08:51
  • 13
    They can reduce your concurrency, but the internal locks cannot cause Deadlock. Deadlock requires operations waiting on one another, and none of the things done inside the locks can call back out to your code that could try to do something that also needs a lock. – me22 Sep 12 '13 at 23:03
  • True! I stand corrected. I still highly recommend the linked blog entry for reference on the internals of the concurrent collections, though. – DuneCat Oct 02 '14 at 14:48
8

All of the answers so far are great and helpful, but I think the link that DuneCat pointed out in one of the comments bears emphasis:

http://geekswithblogs.net/simonc/archive/2012/02/22/inside-the-concurrent-collections-concurrentdictionary.aspx

Specifically.....

Lockless:

  • TryGetValue
  • GetEnumerator
  • The indexer getter
  • ContainsKey

Takes out every lock (lockfull?):

  • Count
  • IsEmpty
  • Keys
  • Values
  • CopyTo
  • ToArray
RJB
  • 2,063
  • 5
  • 29
  • 34
  • Wayback Machine link to URL: https://web.archive.org/web/20201126014423/http://geekswithblogs.net/simonc/archive/2012/02/22/inside-the-concurrent-collections-concurrentdictionary.aspx – Tobey Blaber Jun 12 '22 at 03:31