2009-10-08 2 views
1

Так что это очень конкретный вопрос:Является ли эта тема безопасной? (общие данные без мьютекса/семафора)

Я использую встроенную систему с одним ядром процессора.

У меня есть один основной поток и прерывание. Они имеют 32-битный флоат. Прерывание записывает float, и основной поток читает его. Считывание и запись не синхронизированы.

В документации к процессору указано, что 32-разрядное считывание является однотактной.

Могу ли я в своей оценке, что нет риска, что основной поток будет читать поврежденное значение? Или есть другие факторы?

ответ

2

Пока оба чтения и записи являются атомными операциями, все должно быть хорошо. Как долго чтение или запись является несущественным, хотя кажется вероятным, что они являются атомарными, если они являются 1 циклом.

+0

Имеет ли значение, является ли запись двумя циклами? –

+0

И чтение, и запись должны быть атомарными, чтобы это работало. Если это так, вам хорошо идти. Если есть проблема с этим, вы можете найти некоторую операцию памяти, где чтение и запись являются как атомарными, так и байтами. Тогда вы можете использовать это как семафор, чтобы ограничить доступ чтения/записи к float. –

+0

Кроме того, всегда ли верно, что однотактные операции являются атомарными на одиночных ядрах? В документации явно указано, что test_and_set является атомарным. –

0

Я думаю, что вы в порядке, пока процедура прерывания не считывает значение, а затем использует значение для вычисления нового значения для записи.

В документации также указано, что запись занимает один цикл? Если нет, то вам нужна защита.

0

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

0

Атомные чтения/записи, возможно, не единственное соображение, чтобы сделать операции потокобезопасными. Я думаю, что ответ будет зависеть и от модели памяти ОС. Вы должны убедиться, что чтение в вашем основном потоке получит самое последнее значение, записанное прерыванием.

+1

Поскольку он работает только на одном ядре, память процессора не вступает в силу - модели памяти CPU имеют наибольшее значение, когда разные ядра могут видеть считывания/записи в другом порядке, чем они были выданы другим процессором. – Michael

+0

Не может ли быть, что код повторного заказа компилятора может вызвать проблему на одной основной машине? –

+0

Когда вы сказали модель памяти, я предположил, что вы имели в виду модель памяти процессора. Переупорядочение компилятора по-прежнему будет фактором (скорее всего, будет изменчивым). – Michael

1

Звучит так, как будто вы в безопасности. Если чтение выполняется сразу, никто не может писать только половину байтов. После этого вам нужно убедиться, что значение всегда действительно читается вашим потоком, а не оптимизировано компилятором. Это может произойти, если компилятор считает, что никто не может изменить переменную извне. Объявление его как изменчивого должно делать трюк (если применимо вообще - я не знаком с вашим кодом).