Обещанный to be continued

Автор: samius
Дата: 24.02.17

:

        private static readonly SpinLock _lock = new SpinLock();

        private static int _value = 0;

        private static void Increment()
        {
            bool ok = false;
            try
            {
                _lock.Enter(ref ok);

                _value++;

                // ...
            }
            finally
            {
                if (_lock.IsHeld)
                    _lock.Exit(true);
            }
        }

        static void Main(string[] args)
        {
            Parallel.For(0, 100000, i => Increment());
            Console.WriteLine($"Actual: {_value};");

            Console.WriteLine("Done.");
            Console.ReadKey();
        }

Что не так-то?

Здравствуйте, Sinix, Вы писали:

private static readonly SpinLock _lock = new SpinLock();

Resharper подсвечивает: "Impure method is called for readonly field of value type".

Если readonly есть, то доступ к переменной _lock внутри Increment() идет через ldsfld(кладет на стек значение статического поля, все Increment работают со своим SpinLock).
Если readonly нет, то доступ к переменной _lock внутри Increment() идет через ldsflda(кладет на стек адрес статического поля, все Increment работают с одним SpinLock).

Здравствуйте, StatujaLeha, Вы писали:

SL>Resharper подсвечивает: "Impure method is called for readonly field of value type".
Спойлеры же


SL>все Increment работают со своим SpinLock
Не совсем так, всё ещё эпичней. Попробуйте убрать соломку от Thread.Abort(), закомментировав if (_lock.IsHeld).

По теме — та же самая ошибка, что с ImmutableArray<T>. Попытка запихнуть в public API тип с нелогичным поведением ни к чему хорошему не приводит.

Здравствуйте, Sinix, Вы писали:

S>

private static readonly SpinLock _lock = new SpinLock();

S>Что не так-то?

Не похожее ли было у Джона Скита (Jon Skeet): micro-optimization-the-surprising-inefficiency-of-readonly-fields

Здравствуйте, Sinix, Вы писали:

S>Не совсем так, всё ещё эпичней. Попробуйте убрать соломку от Thread.Abort(), закомментировав if (_lock.IsHeld).

Cool.
Если соломку заменить на if (ok), то оказывается, что это не соломка :D
Чем в данном примере if (ok) отличается от if (_lock.IsHeld)?

Здравствуйте, StatujaLeha, Вы писали:

SL>Cool.
SL>Если соломку заменить на if (ok), то оказывается, что это не соломка :D
SL>Чем в данном примере if (ok) отличается от if (_lock.IsHeld)?

да ничем, if (ok) — та же соломка, только аккуратнее. В смысле, с if (ok) оно хоть исключение бросать будет.

Здравствуйте, Qbit86, Вы писали:

Q>Не похожее ли было у Джона Скита (Jon Skeet): surprising-inefficiency-of-readonly-fields
Угу, было

Автор: Sinix
Дата: 23.04.16

.

Тут тоже, конечно, surprising, только не совсем inefficiency. Даж наоборот. Итоговая сумма меньше => экономия налицо

Здравствуйте, Sinix, Вы писали:

S>Обещанный to be continued

Автор: samius
Дата: 24.02.17

:

Пффф. Я на эти грабли IRL наступил

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, StatujaLeha, Вы писали:

SL>>Cool.
SL>>Если соломку заменить на if (ok), то оказывается, что это не соломка :D
SL>>Чем в данном примере if (ok) отличается от if (_lock.IsHeld)?

S>да ничем, if (ok) — та же соломка, только аккуратнее. В смысле, с if (ok) оно хоть исключение бросать будет.
IsHeld там вообще не по делу, может привести еще и к поломке SpinLock при избыточном вызове Exit.

Здравствуйте, hardcase, Вы писали:

S>>Обещанный to be continued

Автор: samius
Дата: 24.02.17

:

H>Пффф. Я на эти грабли IRL наступил

Тож Почти все посты этой серии — только из реального кода. Если не считать позаимствованных конечно, в них я авторство указываю. Иначе какой тут WTF-то?

Здравствуйте, samius, Вы писали:

S>IsHeld там вообще не по делу, может привести еще и к поломке SpinLock при избыточном вызове Exit.



По памяти восстанавливал, накосячил. Там наверно IsHeldByCurrentThread был.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>По памяти восстанавливал, накосячил. Там наверно IsHeldByCurrentThread был.
А я подумал, что это часть засады WTF.
IsHeldByCurrentThread просит еще и enableThreadOwnerTracking в конструкторе.

Все равно, не дешевле ли ok проверить, особенно на Exit, вызванном в том же методе, где и Enter? Ладно бы еще в разных методах, куда лениво bool тащить.

Здравствуйте, samius, Вы писали:

S>Все равно, не дешевле ли ok проверить, особенно на Exit, вызванном в том же методе, где и Enter? Ладно бы еще в разных методах, куда лениво bool тащить.
+1
Ну вот такой вот код достался
Впрочем, не факт, что я бы сходу лучше написал. Если конечно меня бы кто убедил, что тут нужен именно SpinLock.

Здравствуйте, Sinix, Вы писали:

S>Впрочем, не факт, что я бы сходу лучше написал. Если конечно меня бы кто убедил, что тут нужен именно SpinLock.
Сам давно его стороной обхожу.