jcopenha верна, но я просто хотел ответить на вопрос: «Беспокойство касается только многопроцессорных систем?»
Я не знаю, какой Interlocked вы используете. Если вы имеете в виду c ++, то на одноядерном вы «должны быть» безопасны для выполнения «++ x», если x не больше вашей «битности». Я пишу «должно быть», потому что компилятор может оптимизировать его каким-то странным образом в функции - например, заменить два «++ x» на обычные «add ..., 2» в совершенно другом месте и часть вашей многопоточности логика может потерпеть неудачу из-за этого. На многоядерном языке даже ++ x на 32-битном x может иметь странные эффекты (инструкция может быть «inc mem» или «lock inc mem»), и когда вы увеличиваете один адрес mem из двух процессоров, когда он не заблокирован, вы получить странные результаты).
Если «битность» вашего x выше, чем у вашего процессора, тогда вам необходимо блокировать любой многопоточный код - не имеет значения, одно- или многоядерный, потому что эта инструкция в любом случае должна быть скомпилирована в два asm-кода и переключение контекста может произойти между ними. (это можно исправить с помощью RCU)
В .NET это в основном та же история, но вы перегрузили Increment вместо Interlocked ... и Interlocked ... 64.
Так что да - всякий раз, когда вы пишете многопоточные файлы (даже на одноядерных процессорах), просто используйте взаимосвязанные приращения в общей памяти. Здесь не стоит пытаться быть «умнее» машины.