Почему Система использования. Поточная обработка. Взаимно блокируемый. Декремент вместо минус?
Существует несколько тактики, я раньше в прошлом моделировал сетевые проблемы;
- Выходят, сетевой кабель
- Выключают переключатель (идеально с переключателем, что компьютер включается в то, чтобы все еще быть приводимым в действие, таким образом, машина поддерживает, это - "сетевое соединение") между Вашей машиной и "целевой" машиной
- программное обеспечение брандмауэра Выполнения на целевой машине, которая тихо отбрасывает полученные данные
, Одна из этих идей могла бы дать Вам некоторые средства искусственной генерации сценария, в котором Вы нуждаетесь
5 ответов
Комментарий Михала Пясковского вызвал следующее объяснение:
Семантика i - в C # должна возвращать текущее значение i ( т.е. значение до того, как произойдет декремент), а затем уменьшите i на 1.
Итак, нам нужно преобразовать это в VB. Мы не можем использовать i - = 1 , потому что это не возвращает текущее значение i перед декрементом. Итак, нам нужна операция, которая будет уменьшать i , но возвращать значение i перед декрементом, что-то вроде:
Function DoPostDecrement(ByRef i As Integer) As Integer
i -= 1
Return i + 1
End Function
Но это предлагает использовать следующее, чтобы избежать необходимости писать метод для выполнения вышеуказанного:
System.Math.Max(
someValueThatIsEqualToiMinusOne,
someValueThatIsEqualtoiBeforeTheDecrement
)
Но VB.NET не позволит вам использовать i - = 1 или i = i - 1 вместо someValueThatIsEqualToiMinusOne . Однако, System.Threading.Interlocked.Decrement (i) допустимо и равно значению i - 1 . После этого, поскольку параметры оцениваются слева направо, someValueThatIsEqualtoiBeforeTheDecrement должно быть i + 1 (в этот момент декремент был выполнен до i + 1 - значение до декремента.
Обратите внимание, что вышеуказанный метод DoPostDecrement и конструкция System.Math.Max, System.Threading.Interlocked.Decrement могут иметь различную семантику в многопоточный контекст.
Связанная операция является атомарной ; в многопоточном контексте вы можете безопасно использовать его без блокировки, если будете осторожны.
Единственная причина, которую я вижу, - это
Decrement a указанная переменная и сохраняет результат как атомарный
Чтобы ответить на ваш вопрос, выглядит вот такая штука converter.telerik.com чрезмерно консервативен в отношении проблем с потоками. WAAAY чрезмерно консервативен. Я бы вернул код на i - , если один и тот же экземпляр i не мутировал одновременно из нескольких потоков.
Это зависит от того, является ли «i» общей переменной? Находится ли он в потокобезопасной среде?
Если «i» является целым числом, то i-- выполняет следующие действия (игнорируя детали):
- вычитает единицу из i
- присваивает это значение обратно i
Как видите, шагов больше 1. Если «i» находится в небезопасном для потоков месте (статическая переменная, совместно используемая между потоками и т. Д.), То поток потенциально может остановиться в середине этих двух шагов, другой поток может выполнить оба шага, и тогда у вас будет проблема с неверными данными.
Класс Interlocked по существу объединяет два вышеуказанных шага в один шаг, обеспечивая атомарную операцию. Теперь вам не нужно беспокоиться о потоках, поскольку это отдельная операция, и ее не может прервать другой поток.