Суть в том, что ИНС позволяет определять положение в пространстве и перепроверять показания датчиков, выявить тот что выдает неадекватные показания.
Как минимум можно добиться того, что бы система понимала, что самолету не угрожает сваливание и она не пыталась его угробить, только потому что один из датчиков сбоит.
У меня не получилось играя с volatile вынудить компилятор сделать что то особенное. Компилятор просто ограничивался вполне очевидными инструкциями записи в память в правильном порядке и всё. Но я от него другого и не ожидал, потому что это уже должна быть забота программиста.
Если надо работать с железом и важен порядок записи в память, то лучше сразу копать в сторону ядра и драйверов устройств. www.kernel.org/doc/Documentation/memory-barriers.txt
Проще всего конечно будет найти хороший пример для подражания и следовать ему.
Во первых это ссылка не на стандарт, а на чей то пересказ.
Во вторых в статье как раз опровергают ваш вывод — у вас данные не volatile. Там у них тоже кастуется к volatile * и через него перезаписывается и они пишут, что в этом случае стандарт не гарантирует.
В третьих — всё что стандарт может гарантировать, это что компилятор сгенерирует машинный код где нужные инструкции записи в память будут присутсвовать в нужном порядке. Стандарт не может гарантировать, что процессор исполнит их именно в таком порядке. Это уже личное дело процессора.
Посмотрите en.wikipedia.org/wiki/Memory_barrier
Там автор не до конца понимает о чем пишет.
Он даже синтаксис языка не до конца понимает (вот отличный перл: «const int const * const p = &i»).
Но в целом он тоже упомянул, что volatile не гарантирует порядка исполнения/записи в память и необходимость использования дополнительных механизмов вроде memory barrier.
Т.е. в приведенном примере если записывать не нули, а например 1, 2, 3, то нет гарантии того, что они будут записаны в таком порядке, а не вперемешку.
Не, не гарантируется.
Даже если сами на ассемблере напишите, порядок все равно не гарантируется.
процессор волен исполнять инструкции так как ему удобнее.
Более того, у х86 ассемблер это всего лишь внешний программный интерфейс, внутри процессора инструкции декодируются в микрооперации и исполняются в произвольном порядке.
Даже когда вы думаете что считываете переменную в регистр, на самом деле в процессоре там целый пул этих регистров и он может параллельно выполнять инструкции завязанные на один и тот же программный регистр.
Все что может компилятор — это сгенерировать машинный код.
На уровне машинного кода, да — volatile обяжет компилятор добавить операции чтения/записи с памятью.
В вашем первом примере компилятор вообще может выкинуть инициализацию переменных.
это прекрасно работает еще со времен одноядерных процессоров.
можно запустить «сложные вычисления длительностью больше кванта времени» в низкоприоритетном потоке и никаких тормозов заметно не будет.
Оно и сейчас будет работать.
Речь о том, что с volatile компилятор вставит реальное чтение/запись с памятью и процессор тоже со временем все сделает так как было задуманно.
Если не особо критично в какой конкретно момент времени это должно произойти, то все сработает как задумывалось.
Другое дело, что лучше использовать нормальные средства для синхронизации, а не колхозить.
я не писал про математическую верифицируемость — я писал про то, что если есть вероятность отказа определенного датчика, то система должна анализировать разные источники данных что бы диагностировать отказ.
тут инженеры боинг явно облажались.
я написал только то что написал.
атомарность и volatile разные вещи, а запись/чтение регистра в память атомарны почти везде.
т.е. переменную не искорежит при этом.
колхозить на этом механизм синхронизации я не предлагал.
Вы не понимаете что такое атомарность.
В данном случае речь идет не о чтение-сравнении-записи, а просто о чтении или записи. Теоритически, если переменная не выровнена в памяти и не влезает в регистр (не может быть считана в регистр за раз), то возможна ситуация когда будет считана только часть переменной, а позже будет дочитан уже кем то измененный остаток.
Только это все не про volatile.
Нужно информацию с разных датчиков комбинировать (Sensor Fusion), тогда будет понятно, что это не самолет падает, а датчик врёт.
Ведь в самолете помимо датчиков подверженных внешним воздействиям есть инерциальная система (акселерометры, гироскопы) и GPS.
Как минимум можно добиться того, что бы система понимала, что самолету не угрожает сваливание и она не пыталась его угробить, только потому что один из датчиков сбоит.
Если надо работать с железом и важен порядок записи в память, то лучше сразу копать в сторону ядра и драйверов устройств.
www.kernel.org/doc/Documentation/memory-barriers.txt
Проще всего конечно будет найти хороший пример для подражания и следовать ему.
Во вторых в статье как раз опровергают ваш вывод — у вас данные не volatile. Там у них тоже кастуется к volatile * и через него перезаписывается и они пишут, что в этом случае стандарт не гарантирует.
В третьих — всё что стандарт может гарантировать, это что компилятор сгенерирует машинный код где нужные инструкции записи в память будут присутсвовать в нужном порядке. Стандарт не может гарантировать, что процессор исполнит их именно в таком порядке. Это уже личное дело процессора.
Посмотрите en.wikipedia.org/wiki/Memory_barrier
Он даже синтаксис языка не до конца понимает (вот отличный перл: «const int const * const p = &i»).
Но в целом он тоже упомянул, что volatile не гарантирует порядка исполнения/записи в память и необходимость использования дополнительных механизмов вроде memory barrier.
Т.е. в приведенном примере если записывать не нули, а например 1, 2, 3, то нет гарантии того, что они будут записаны в таком порядке, а не вперемешку.
Даже если сами на ассемблере напишите, порядок все равно не гарантируется.
процессор волен исполнять инструкции так как ему удобнее.
Более того, у х86 ассемблер это всего лишь внешний программный интерфейс, внутри процессора инструкции декодируются в микрооперации и исполняются в произвольном порядке.
Даже когда вы думаете что считываете переменную в регистр, на самом деле в процессоре там целый пул этих регистров и он может параллельно выполнять инструкции завязанные на один и тот же программный регистр.
Все что может компилятор — это сгенерировать машинный код.
На уровне машинного кода, да — volatile обяжет компилятор добавить операции чтения/записи с памятью.
В вашем первом примере компилятор вообще может выкинуть инициализацию переменных.
можно запустить «сложные вычисления длительностью больше кванта времени» в низкоприоритетном потоке и никаких тормозов заметно не будет.
Речь о том, что с volatile компилятор вставит реальное чтение/запись с памятью и процессор тоже со временем все сделает так как было задуманно.
Если не особо критично в какой конкретно момент времени это должно произойти, то все сработает как задумывалось.
Другое дело, что лучше использовать нормальные средства для синхронизации, а не колхозить.
люди не понимают, что атомарность и volatile в разных плоскостях находятся.
тут инженеры боинг явно облажались.
атомарность и volatile разные вещи, а запись/чтение регистра в память атомарны почти везде.
т.е. переменную не искорежит при этом.
колхозить на этом механизм синхронизации я не предлагал.
В данном случае речь идет не о чтение-сравнении-записи, а просто о чтении или записи. Теоритически, если переменная не выровнена в памяти и не влезает в регистр (не может быть считана в регистр за раз), то возможна ситуация когда будет считана только часть переменной, а позже будет дочитан уже кем то измененный остаток.
Только это все не про volatile.
и volaitile тут ни при чем.
Ведь в самолете помимо датчиков подверженных внешним воздействиям есть инерциальная система (акселерометры, гироскопы) и GPS.
и чтение атомарно.
code.fb.com/android/improving-facebook-s-performance-on-android-with-flatbuffers