Потокобезопасный ленивый класс

Разве вы не можете просто полностью отказаться от повторной оценки функции, используя либо флаг, либо защитное значение для реального значения? То есть:

public sealed class Lazy<T>
{
    Func<T> f;
    T value;
    volatile bool computed = false;
    void GetValue() { lock(LockObject) { value = f();  computed = true; } }

    public Lazy(Func<T> f)
    {
        this.f = f;
    }

    public T Force()
    {
        if (!computed) GetValue();
        return value;
    }
}

В вашем коде есть несколько проблем:

1. Вам нужен один объект для блокировки. Не блокируйте изменяемую переменную — блокировки всегда имеют дело с объектами, поэтому, если getValue изменится, несколько потоков могут одновременно войти в заблокированный раздел.

2. Если несколько потоков ожидают блокировки, все они будут вычислять функцию f() друг за другом. Вам нужно будет проверить внутри блокировки, что функция еще не была оценена.

3. Вам может понадобиться барьер памяти даже после устранения вышеуказанных проблем, чтобы делегат был заменен только после того, как новое значение было сохранено в памяти.

Однако вместо этого я бы использовал подход с флагом от Конрада Рудольфа (только убедитесь, что вы не забыли о «изменчивости», необходимой для этого). Таким образом, вам не нужно вызывать делегата всякий раз, когда значение извлекается (вызовы делегата выполняются довольно быстро, но не так быстро, как простая проверка логического значения).

Я не совсем понимаю, что вы пытаетесь сделать с этим кодом, но я просто опубликовал статью в The Code Project о создании своего рода "ленивого" класса, который автоматически асинхронно вызывает рабочую функцию и сохраняет ее значение.

Это больше похоже на механизм кэширования, чем на «ленивую оценку». Кроме того, не изменяйте значение ссылки блокировки в блоке lock. Используйте временную переменную для блокировки.

Ожидание, которое у вас есть прямо сейчас, будет работать в большом количестве случаев, но если бы у вас было два разных потока, попробуйте вычислить выражение в следующем порядке:

Thread 1
Thread 2
Thread 1 completes

Поток 2 никогда не завершится, потому что Поток 1 снимет блокировку с ссылки, отличной от той, которая использовалась для получения блокировки (точнее, он снимет несуществующую блокировку, поскольку вновь созданная ссылка никогда не была заблокирована с самого начала). ) и не снимать исходную блокировку, блокирующую поток 2.

Хотя я не совсем уверен, что это будет делать (помимо выполнения синхронизированной оценки выражения и кэширования результата), это должно сделать его более безопасным:

public sealed class Lazy<T>
{
    Func<T> getValue;
    T value;
    object lockValue = new object();

    public Lazy(Func<T> f)
    {
        getValue = () =>
            {
                lock (lockValue)
                {
                    value = f();
                    getValue = () => value;
                }
                return value;
            };
    }

    public T Force()
    {
        return getValue();
    }
}