Pull to refresh

Comments 8

lock(this) — bad practiсe. Потенциально может привести к дедлоку, если какой-то внешний код (вдруг) будет лочить сам объект контрола. Лучше завести отдельную локальную переменную а-ля object lockObject и делать lock(lockObject).

тут подробные комментарии есть.
Плюсую! Потому-что сам с такой фигней уже воткнулся. Но, я не знаю что стоило выбрать приоритетом для статьи — железную надежность, или простоту восприятия и короткий код. Выбрал — простой короткий код. Тем, кто поопытнее, у них вопросов не возникнет, сами переделают библиотеку под себя, у них нет вопросов, и тестовые семплы WPF и WF им даже не нужны.
А тем, кто только начал кодить, им лучше попроще показать, и если что постепенно, до хардкора доберутся с потоками поиграются, с дебагером. Насколько смог, чтобы всем польза и позитив были.
Немного добавлю. У меня был этот вариант с lockobject и методами BeginPaint() и EndPaint() во фронтэнде, которые через Monitor лочили. Но, стало выглядеть сложнее, хотя и правильнее с точки зрения продакшн. Вот честно, я побоялся напугать заморочками в коде не очень опытных камрадов.
Блин, кажется я комментарием выше сделал рекурсивную ловушку, и теперь эти камрады знают, что они чего-то не знают, что их может напугать.
не думаю, что если вы создадите еще одну приватную переменную с говорящим именем, это сильно усложнит читаемость кода, например:
private readonly object syncObj = new object(); // Переменная, используемая для синхронизации потоков

Не следует перегружать код, но если уж вы взялись за синхронизацию потоков, делайте ее правильно, зачем учить плохому?
Для тех, у кого возникнут вопросы, есть примитивный пример в MSDN:
msdn.microsoft.com/ru-ru/library/c5kehkcz.aspx
Убедили, сделано, сорцы обновил
Sign up to leave a comment.

Articles