Runtime: 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 (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

[karelz]

@hermitdave are you working on it?

[danmosemsft]

@hermitdave do you still have interest in writing up the formal proposal here? If we review okays it promply and someone is interested in implementation, there may still be time to get this into 2.0.

Possibly the implementation could begin by wrapping ConcurrentDictionary, so the API is quickly available to use, then rewritten to have the space/time improvements of a custom implementation.

[daveaglick]

FWIW, @i3arnon has a really nice implementation at https://github.com/i3arnon/ConcurrentHashSet

[hermitdave]

@i3arnon maybe you should do a PR instead.

[danmosemsft]

Just to be clear folks -- feel free to make a PR, but we can't take any change without an API review approval. That needs a proposal written up as above. @hermitdave were you going to do that?

[hermitdave]

@danmosemsft I had a look at what @i3arnon did and it is which is decent. if he isn't interested then I will do a PR later this week

[karelz]

@hermitdave we first need API proposal (see API review process) - i.e. review the API surface of the collection (with motivation and relation to 'classic' HashSet and other concurrent collections).

Just to set expectations: Based on recent discussions around other collections, we will likely have to find the right place for new collections (CoreFX repo might not be the desired destination). That may take even longer.

[danmosemsft]

@hermitdave apologies, I wasn't clear in my comment. I should have said -- feel free to prototype in a fork, but a PR against CoreFX would be noise at this point without API approval

[danmosemsft]

I see a limited use internal one exists. https://github.com/dotnet/corefx/blob/103639b6ff5aa6ab6097f70732530e411817f09b/src/Common/src/CoreLib/System/Diagnostics/Tracing/TraceLogging/ConcurrentSet.cs

[vancem]

Just FYI The implementation Dan refers to above is very specialized (e.g. there is no remove), and is probably not representative.

The C# compiler community wrote a simple wrapper for themselves, that is probably a better representation of what would be done if we wanted to add this class.

http://source.roslyn.io/#microsoft.codeanalysis/InternalUtilities/ConcurrentSet.cs

[eltiare]

I find myself wanting this very much on occasion. Seems like something that shouldn't be overlooked.

[LeaFrock]

@vancem I can't agree more! But three years passed, and no ConcurrentHashSet yet =.=
I think most of us want a kind of collections which is similar to ConcurrentBag, but its elements are never duplicated and its 'Contains()' is an O(1) operation like HashSet.
We can make it using ConcurrentDictionary, but that implementation is too ugly.

[reggaeguitar]

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.

@JohanLarsson Your link is broken

[JohanLarsson]

@reggaeguitar fixed the link.

[markusschaber]

I think most of us want a kind of collections which is similar to ConcurrentBag, but its elements are never duplicated and its 'Contains()' is an O(1) operation like HashSet.

And which allows to remove a specific element, instead of just a random one (I just needed this today, and see https://stackoverflow.com/questions/3029818/how-to-remove-a-single-specific-object-from-a-concurrentbag for another example).

[MgSam]

So no one ever made an API proposal for this? Maybe you guys should add the up-for-grabs label.

[LeaFrock]

@MgSam I can't stand it anymore, so I've spent some time on the API proposal.

Details see #39919 . Let's promote it and finally make it.

[jkotas]

Duplicate of #39919 that has actual API proposal