Обчислювальна твердість "реальних" комп'ютерних програм

Я часто чув, як вона говорила, що ви не можете написати програму, щоб ловити помилки у веб-браузері, текстовому процесорі чи операційній системі, через теорему Райса: будь-яке семантичне властивість для мови, повного Тьюрінга не можна визначити.

Однак я не впевнений, наскільки це стосується реальної програми, що подобається операційним системам. Чи потрібні ці типи програм повною мірою повноти Тьюрінга? Чи є більш прості моделі обчислень (наприклад, PR), в які ці програми можна було б записати? Якщо так, то наскільки це дозволяє визначити правильність програми?

Ви, звичайно, можете писати програми, які виловлюють помилки - існує велика і активна спільнота людей, які пишуть програми, щоб робити саме це. Однак те, що теорема Райса заважає тобі робити, - це писати помилки і є повноцінними (тобто ловити всі помилки певного класу без помилкових позитивних результатів).

Однак, наївні обмеження на модель обчислення насправді не дуже допомагають тобі в покращенні практичності аналізу програм. Причина полягає в тому, що ви можете отримати програми, які роблять «майже те саме», обертаючи цикли

while P do 
   C

в петлі for з великою постійною ітерацією:

for i = 0 to BIGNUM do 
  if P then 
    C
  else
    break

Тепер ця програма навіть не потребує повної сили примітивної рекурсивної (оскільки for-цикл може бути макророзширений у величезну вкладену операцію if-then-else), але в більшості практичних випадків вона буде вести себе так само, як і раніше. Зауважте, що це допомагає теоретично вирішувати - програма загальна, тому ви можете відповідати на запитання, запустивши програму і побачивши, що відбувається. Насправді ми цього не хочемо, а це отримувати відповіді швидше, ніж запускати програму - введене штучне припинення насправді не допомагає аналізу програми на практиці, оскільки помилки виникають через помилки в реальній логіці програми, а у нас немає ' t взагалі цього не торкнувся.

Крім того, додавання засобів абстрагування до мови програмування може кардинально погіршити складність проблеми аналізу, полегшивши перевірку програм на практиці. Наприклад, доведення закінчення просто типізованого обчислення лямбда з натуральними числами вимагає індукції до , але додаючи поліморфізм типу, ви отримуєте Систему F, доказ якої закінчується настільки ж сильною, як послідовність арифметики другого порядку. Однак на практиці програми, написані на F, набагато простіше перевірити, оскільки модульні властивості кількісного визначення другого порядку значно спрощують написання структурованих програм та підтвердження правильності.$\epsilon_0$

Оскільки ви запитували про коректність програм реальних програм, таких як операційні системи, вас може зацікавити проект seL4 ( журнал , pdf , конференція ).

Команда NICTA взяла мікро-ядро третього покоління з 8700 ліній С та 600 ліній асемблера, реалізованих згідно з абстрактною специфікацією в Haskell. Вони надали офіційний перевірений машиною доказ (у Isabelle / HOL), що впровадження суворо відповідає технічним умовам. Таким чином, доведено, що їхня програма відсутня помилок.

Так що, як і проблема зупинки, хоча вона взагалі не може бути вирішена, вона може бути вирішена для деяких конкретних випадків. У цьому випадку, хоча ви не можете довести, що довільний код C не містить помилок, вони могли б зробити це у випадку мікроклетки seL4.

Питання, які ви задаєте, насправді зовсім інші.

Однак я не впевнений, наскільки це стосується реальної програми, що подобається операційним системам. Чи потрібні ці типи програм повною мірою повноти Тьюрінга?

Потрібно вкрай мало, щоб модель обчислення була Тюрінгом завершеною. Наприклад, різні моделі з лічильниками можуть імітувати машини Тьюрінга. Якщо ви вважаєте, що для вашого програмного забезпечення потрібно більше двох лічильників, якими ви можете довільно маніпулювати, ви використовуєте повну мову Тюрінга. Хоча машинні цілі числа є аріорі обмеженими, структури даних, виділені купуми, зазвичай не є. Якщо ваше програмне забезпечення потребує списків, дерев та інших динамічно розподілених даних, ви використовуєте повну мову Turing.

Чи є більш прості моделі обчислень (наприклад, PR), в які ці програми можна було б записати? Якщо так, то наскільки це дозволяє визначити правильність програми?

Важливо визнати, що ми не хочемо перевіряти довільні властивості нашого програмного забезпечення. Перевірка дуже специфічних вузьких властивостей (відсутність переповнення буфера, відсутність відміни нуля-покажчика, відсутність нескінченних циклів тощо) надзвичайно покращує якість та зручність використання програмного забезпечення. Теоретично такі проблеми досі не вирішені. На практиці фокусування на конкретних властивостях дозволяє виявити в наших програмах структуру, яку ми можемо часто використовувати для вирішення проблеми.

Зокрема, ви можете змінити своє оригінальне запитання

Чи є абстракція мого програмного забезпечення, яке я можу ефективно проаналізувати в нетурюрській комплектації?

Абстракція - це модель, яка включає поведінку оригінального програмного забезпечення та, можливо, багато додаткових поведінок. Є такі моделі, як машини з одноразовим приладом або системи віджимань, які не є Тьюрінгом завершеними і які ми можемо аналізувати. Стандартний підхід у верифікації програм за допомогою автоматизованих інструментів полягає у побудові абстракції в такій моделі та алгоритмічній її перевірці.

Є додатки, де люди дбають про складні властивості свого обладнання або програмного забезпечення. Апаратні компанії хочуть, щоб їхні чіпи правильно реалізували арифметичні алгоритми, автомобільні та авіонічні компанії хочуть, щоб програмне забезпечення було правильно. Якщо це важливо, вам краще скористатися (навченою) людиною.