Содержит потокобезопасный в HashSet‹T›

Обычно (обычно) коллекции, которые используются только для чтения, являются "неофициально" потокобезопасными (я знаю, что в .NET нет коллекции, которая изменяет себя во время чтения). Есть некоторые предостережения:

• Сами элементы не могут быть потокобезопасными (но с HashSet<T> эта проблема должна быть сведена к минимуму, потому что вы не можете извлекать элементы из него. Тем не менее GetHashCode() и Equals() должны быть потокобезопасными. Если, например, они обращаются к ленивым объектам которые загружаются по запросу, они могут быть не потокобезопасными или, возможно, кэшируют/запоминают некоторые данные для ускорения последующих операций)
• Вы должны быть уверены, что после последней записи есть Thread.MemoryBarrier() (выполняется в том же потоке, что и запись) или эквивалент, иначе чтение в другом потоке может считать неполные данные.
• Вы должны быть уверены, что в каждом потоке (отличном от того, где вы делали запись) перед выполнением первого чтения есть Thread.MemoryBarrier(). Обратите внимание, что если HashSet<T> был "подготовлен" (с Thread.MemoryBarrier() в конце) перед созданием/запуском других потоков, то Thread.MemoryBarrier() не нужен, потому что потоки не могут иметь устаревшее чтение памяти (потому что их не было). Различные операции вызывают неявный Thread.MemoryBarrier(). Например, если потоки, созданные до заполнения HashSet<T>, вошли в Wait() и были un-Waited после заполнения HashSet<T> (плюс его Thread.MemoryBarrier()), выход из Wait() вызывает неявный Thread.MemoryBarrier()

Простой пример класса, который использует мемоизацию/ленивую загрузку/как бы вы это ни называли, и таким образом может нарушить потокобезопасность.

public class MyClass
{
    private long value2;

    public int Value1 { get; set; }

    // Value2 is lazily loaded in a very primitive
    // way (note that Lazy<T> *can* be used thread-safely!)
    public long Value2
    {
        get
        {
            if (value2 == 0)
            {
                // value2 is a long. If the .NET is running at 32 bits,
                // the assignment of a long (64 bits) isn't atomic :)
                value2 = LoadFromServer();

                // If thread1 checks and see value2 == 0 and loads it,
                // and then begin writing value2 = (value), but after
                // writing the first 32 bits of value2 we have that
                // thread2 reads value2, then thread2 will read an
                // "incomplete" data. If this "incomplete" data is == 0
                // then a second LoadFromServer() will be done. If the
                // operation was repeatable then there won't be any 
                // problem (other than time wasted). But if the 
                // operation isn't repeatable, or if the incomplete 
                // data that is read is != 0, then there will be a
                // problem (for example an exception if the operation 
                // wasn't repeatable, or different data if the operation
                // wasn't deterministic, or incomplete data if the read
                // was != 0)
            }

            return value2;
        }
    }

    private long LoadFromServer()
    {
        // This is a slow operation that justifies a lazy property
        return 1; 
    }

    public override int GetHashCode()
    {
        // The GetHashCode doesn't use Value2, because it
        // wants to be fast
        return Value1;
    }

    public override bool Equals(object obj)
    {
        MyClass obj2 = obj as MyClass;

        if (obj2 == null)
        {
            return false;
        }

        // The equality operator uses Value2, because it
        // wants to be correct.
        // Note that probably the HashSet<T> doesn't need to
        // use the Equals method on Add, if there are no
        // other objects with the same GetHashCode
        // (and surely, if the HashSet is empty and you Add a
        // single object, that object won't be compared with
        // anything, because there isn't anything to compare
        // it with! :-) )

        // Clearly the Equals is used by the Contains method
        // of the HashSet
        return Value1 == obj2.Value1 && Value2 == obj2.Value2;
    }
}

Учитывая, что вы заранее загружаете свой набор значений, вы можете использовать ImmutableHashSet<T> из библиотеки System.Collections.Immutable. неизменяемые коллекции рекламируют себя как потокобезопасный, поэтому нам не нужно беспокоиться о «неофициальной» безопасности потоков HashSet<T>.

var builder = ImmutableHashSet.CreateBuilder<string>(); // The builder is not thread safe

builder.Add("value1");
builder.Add("value2");

ImmutableHashSet<string> set = builder.ToImmutable();

...

if (set.Contains("value1")) // Thread safe operation
{
 ...
}

От Microsoft: Thread-Safe Collections

В .NET Framework 4 представлено пространство имен System.Collections.Concurrent, которое включает несколько классов коллекций, которые являются потокобезопасными и масштабируемыми. Несколько потоков могут безопасно и эффективно добавлять или удалять элементы из этих коллекций, не требуя дополнительной синхронизации в пользовательском коде. Когда вы пишете новый код, используйте классы параллельных коллекций всякий раз, когда несколько потоков будут одновременно записывать в коллекцию. Если вы читаете только из общей коллекции, вы можете использовать классы в пространстве имен System.Collections.Generic. Мы рекомендуем вам не использовать классы коллекций 1.0, если только вам не требуется ориентироваться на . NET Framework 1.1 или более ранней версии среды выполнения.

Поскольку Contains не изменяет коллекцию, это просто операция чтения, а поскольку HashSet находится в System.Collections.Generic, одновременный вызов Contains абсолютно допустим.