Являются ли операции чтения и записи свойств атомарными в C#?

Вам нужно более четко различать «атомарные» и «поточно-ориентированные». Как вы сказали, записи являются атомарными для большинства встроенных типов значений и ссылок.

Однако это не означает, что они потокобезопасны. Это просто означает, что если оба значения "A" и "B" записаны, поток никогда не увидит что-то среднее между ними. (например, изменение с 1 на 4 никогда не покажет 5, или 2, или любое другое значение, кроме 1 или 4.) Это не означает, что один поток увидит значение "B", как только это было записано в переменную. Для этого вам нужно взглянуть на модель памяти с точки зрения волатильности. Без барьеров памяти, обычно получаемых с помощью блокировок и/или изменчивых переменных, запись в основную память может быть отложена, а чтение может быть ускорено, фактически предполагая, что значение не изменилось с момента последнего чтения.

Если бы у вас был счетчик, и вы запросили его последнее значение, но никогда не получили последнее значение из-за отсутствия барьеров памяти, я не думаю, что вы могли бы разумно назвать это потокобезопасным, даже если каждый операция вполне может быть атомарной.

Однако это не имеет ничего общего со свойствами — свойства — это просто методы с синтаксическим сахаром вокруг них. Они не дают никаких дополнительных гарантий в отношении многопоточности. Модель памяти .NET 2.0 действительно имеет больше гарантий, чем модель ECMA, и вполне возможно, что она дает гарантии в отношении входа и выхода метода. Эти гарантии должны применяться и к свойствам, хотя я бы побеспокоился об интерпретации таких правил: иногда бывает очень трудно рассуждать о моделях памяти.

Я немного не понимаю, о чем вы здесь спрашиваете. Кажется, вы могли бы задать 1 из 2 вопросов

1. Является ли чтение _foo при вызове MyProperty атомарным?
2. Установлено ли возвращаемое значение MyProperty атомарно?

Для № 1 ответ - да. Как указано в спецификации языка C# (и CLI), чтение и запись переменных определенных указанных типов гарантированно атомарны. Тип 'bool' является одним из таких типов.

Что касается № 2, лучше всего искать его в разделе 12.6.6 спецификации CLI. В нем говорится, что

Соответствующий интерфейс командной строки должен гарантировать, что доступ для чтения и записи к правильно выровненным ячейкам памяти, не превышающим собственный размер слова (размер собственного типа int), является атомарным.

Учитывая, что для использования возвращаемого значения MyProperty вы должны либо читать, либо записывать значение, можно с уверенностью предположить, что оно установлено атомарно.

Атомарность просто означает, что если в переменную записывается более одного потока, ее значение не будет повреждено (например, если оно занимает два байта, вы никогда не получите старший байт потока и младший байт потока два). Это не означает, что переменная является потокобезопасной. Вы все еще можете получить обычные проблемы с потоками, когда один поток не видит других изменений и т. д.

Для потокобезопасности вам нужно использовать блокировку (или volatile, но об этом сложнее рассуждать). В свойствах нет ничего особенного — их тоже нужно сделать явно потокобезопасными.

Если вы изучите автоматически сгенерированный код, вы увидите, что автоматически сгенерированные свойства НЕ являются потокобезопасными — их просто получить/установить в сгенерированное поле. На самом деле, это было бы слишком большим ударом по производительности (особенно когда это не нужно).

Кроме того, если вы планируете получать доступ к значениям int/bool из нескольких потоков, вам следует пометить его (поле) как изменчивый. Это в основном предотвращает проблемы многопоточности, связанные с регистрами ЦП. (Это дополнение к блокировке, а не альтернатива)

Я бы не подумал. Свойства — это, по сути, просто методы с небольшим количеством синтаксического сахара, чтобы с ними было немного легче работать. Таким образом, по умолчанию они не более потокобезопасны, чем обычный вызов метода (то есть вообще не потокобезопасны).

Вы можете поместить что угодно в свойство, например

    Public Property foo() As Boolean
        Get
           goToLunch()
           barbecueRibs()
           return m_foo
        End Get
        Set(ByVal value As Boolean)
           takeANap()
           accessDatabase()
           messUpOtherVariables()
           m_foo = value
        End Set
    End Property