Чи може середовище виконання виявляти нескінченний цикл?

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

Для цього питання я визначаю "нескінченний цикл", щоб означати серію інструкцій та пов'язані з ним дані про початковий стек / купу, які при виконанні повертають процес у точно такий же стан (включаючи дані), як він був раніше ініціюючи нескінченну петлю. (Іншими словами, програма, що генерує нескінченно довге десяткове розширення pi, не "застрягла" у "нескінченному циклі", тому що при кожній ітерації у неї є більше цифр pi десь у відповідної пам'яті.)

(Від порталу /programming//q/16250472/1858225 )

Це може бути теоретично можливо для середовища виконання для перевірки таких петель , використовуючи наступну процедуру:

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

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

Зверніть увагу, звичайно, що це не є проблемою зупинки; відмінність обговорюється тут .

Але така особливість була б величезною тратою ресурсів ; Постійно призупиняючи процес збереження всієї пов'язаної з ним пам'яті, це сповільнить її надзвичайно і дуже швидко витратить величезну кількість пам'яті. (Хоча старі зображення можна буде видалити через деякий час, було б ризиковано обмежити загальну кількість зображень, які можна зберегти, оскільки великий нескінченний цикл - тобто один із багатьма станами - може не потрапити, якщо їх надто мало держави, що зберігаються в пам'яті. і визнання логічної помилки).

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

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

Відповідно до цих надзвичайно неймовірних, але теоретично не обмежуючих припущень, ми можемо дублювати програму та запускати її за два окремі періоди виконання; кожен зробить точно такі ж обчислення.

Тож давайте це зробимо. Ми запустимо його один раз під час виконання Черепахи, і в той же час будемо виконувати його під час виконання Зайця. Однак ми домовляємось, щоб час Зайця працював рівно вдвічі швидше; щоразу, коли час виконання черепахи робить один крок, час виконання Зайця робить два кроки.

$n$$p$$kn$$k$$kn\ge p$

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

Як випливають із термінів, які я використав, це лише відомий алгоритм виявлення циклу « Черепаха та Заєць» Роберта Флойда .

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

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

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

Звичайно, на практиці, мабуть, більше шансів потрапити в такі ситуації, як генерування цифр числа pi --- речі продовжують змінюватися, але ніколи не закінчуються. Ще одна часта можливість полягає в тому, що нескінченний цикл виділяє пам'ять, і в цьому випадку вона швидко вичерпує всю наявну пам'ять.

У моєму курсі з алгоритмів та структур даних, наш автоградер має справу з поданнями студентів, які іноді потрапляють у нескінченні цикли. Для цього переймається 30-секундний тайм-аут і певний обмеження пам’яті. Обидва значно слабкіші, ніж тривалість виконання та бюджети пам’яті, які ми накладаємо в рамках оцінки. Я не впевнений, чи втілення виявлення справжнього нескінченного циклу мало б багато сенсу в цьому контексті, оскільки такі програми працюватимуть трохи повільніше (саме тут може допомогти апаратне забезпечення для хешування стану, але знову ж вам знадобиться додаткове використання для обґрунтуйте це). Коли студенти знають, що їх програма закінчилася, вони зазвичай можуть знайти нескінченний цикл.

У AProVE термінації інструмент виконує статичний аналіз на перезапис системах ( в тому числі підкласу програм Haskell) , які можуть опинитися незавершеного, що дає реальний приклад , НЕ кінцевої програму. Методика досить потужна і працює з використанням варіанту методики, що називається звуженням .

Наскільки я знаю, не було багато роботи з виявлення фактичного неприпинення для загальних мов.