What about adding a ConcurrentSet<T>?

[JohanLarsson]

The need for it comes up every now and then. To me it would make sense next to ConcurrentDictionary<TKey, TValue>

[ayende]

What does this gives you that ConcurrentDictionary<T, object> (and just not using the value) ?

[JohanLarsson]

Nothing but communicates intent better imo. I usually do stuff like this (not a proper set).
Set operations are perhaps tricky to get right with concurrency.

[svick]

@ayende Apart from the "it's clearer what this code does" reason and the precedent of having HashSet<T>, there is a small, but measurable, difference in performance and memory consumption.

A very simple test: when I add a million values to Dictionary<int, int>, it takes 42 ms and consumes 26.6 MB of memory, while with HashSet<int>, it takes 38 ms and consumes 21.3 MB.

I assume the difference with concurrent collections would be similar.

[JonHanna]

If anything more so, since the concurrency consideration means there are a few spots that want to be particularly efficient, so not having to do anything with values would be an even greater gain there than with HashSet<T>.

[svick]

@JohanLarsson

Set operations are perhaps tricky to get right with concurrency.

I think a ConcurrentSet would be useful even without set operations.

[JonHanna]

I know of one C# concurrent hash set and one in Java and neither offer concurrency on set operations, only on the add, remove, contains.

[hermitdave]

Is there's plan to add this? If there is and it's up for grabs, I can look into it

[svick]

@hermitdave You might want to have a look at how the API review process works.

[hermitdave]

Thanks @svick will keep an eye on this one

[JohanLarsson]

@svick

I think a ConcurrentSet would be useful even without set operations.

Agreed, perhaps it should not be called Set? IDK.

[Priya91]

@hermitdave Do you have a proposal for this ?

[hermitdave]

@Priya91 oops forgot about this one.. I'll get started asap

[hermitdave]

Starting work on this