1. C# / Говнокод #20034

    +2

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    private long m_IsExecuting;

// ...

public virtual void Execute(object parameter)
{
	try
	{
		if (Interlocked.Read(ref m_IsExecuting) != 0)
			return;
		Interlocked.Increment(ref m_IsExecuting);
		m_Execute(parameter);
	}
	finally
	{
		Interlocked.Decrement(ref m_IsExecuting);
	}
}

    А за то, что ты меня не пустил, я пущу следующего.

    Запостил: yamamoto, 18 Мая 2016

    Комментарии (12) RSS

    • ava Hubactep 18.05.2016 15:36 # +6

      Слона то вы батенька и не заметили
      Класс Interlocked гарантирует атомарность операция только в своих методах, поэтому при переключении потоков между 9 и 11 строкой ваша блокировка идёт по пизде.
      Но патч в виде
      if (Interlocked.Increment(ref m_IsExecuting) != 1) return;

      вместо строк 9 - 11 решил бы сразу две проблемы
      Ответить

      • ava yamamoto 18.05.2016 16:26 # 0

        Спасибо, кэп!
        Но пропуск каждого второго выглядит забавнее :)
        Ответить

      • ava guesto 18.05.2016 17:47 # +2

        иными словами операции Interlocked атомарны, но между ними может произойти переключение поток. Верно?
        Ответить

      • ava kerman 18.05.2016 23:46 # 0

        Не решил бы. Для первого запуска сработает, но для второго проблема в том, что декремент не обнулит приватку, ибо хуй его знает, сколько раз была проверка с побочным инкрементом.
        Ответить

        • ava Hubactep 19.05.2016 12:14 # +2

          Декремент обнулит так как вызывается даже после return
          Ответить

        • ava inkanus-gray 19.05.2016 12:56 # +3

          return передаёт управление на finally. Декремент рано или поздно сработает, хоть при пропуске m_Execute, хоть после выполнения. Да, m_IsExecuting может принимать значения больше единицы, но после прохождения Execute всеми потоками получим ноль.

          Неприятность возникнет только в случае необработанного исключения, поскольку секции catch у нас нет. Тогда выполнение может быть заблокировано навсегда.
          Ответить

          • ava Hubactep 20.05.2016 17:22 # +3

            Не возникнет блок finally выполняется даже если catch исключение не ловить исключение просто пробрасывается дальше
            Ответить

            • ava inkanus-gray 20.05.2016 17:46 # 0

              Тогда выходит, что проблема решена.

              Я решил подстраховаться, потому что тут было предупреждение:
              https://msdn.microsoft.com/ru-ru/library/zwc8s4fz.aspx
              Но там уже про крайний случай, когда приложение должно аварийно завершиться.
              Ответить

              • ava bormand 20.05.2016 19:12 # +2

                Обработка необработанных исключений

                Какие-то взаимоисключающие параграфы...
                Ответить

                • ava inkanus-gray 20.05.2016 22:11 # +3

                  Вся Винда — это скопление взаимоисключающих параграфов.

                  Windows производит настройку самонастраивающихся устройств.
                  Ответить

    Добавить комментарий