Как разрешить концепцию округлости в программе без бесконечных вычислительных ресурсов? - PullRequest
0 голосов
/ 12 марта 2020

Это может звучать как очень странный вопрос. Но я работаю над проектом, в котором должны быть циклические ссылки. На самом деле, их даже нельзя избежать. Потому что пользователи могут создавать свои собственные циклические ссылки в GUI. И это абсолютно преднамеренно ... Пожалуйста, не спрашивайте, почему, объяснения потребуются целую вечность.

Все вопросы, ответы, ресурсы, которые я нашел, которые обсуждают Циркулярные ссылки, предоставляют решения и подходы о том, как их избежать. , Но кроме того, что я читал, я нашел решение о том, как его создать, не убивая основные вычислительные ресурсы.

Проблемы, которые я вижу

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

Это связано с моим пониманием того, что предоставляемые ресурсы всегда конечны, но циклические ссылки бесконечны по своей природе.

Ресурсы, которые я вижу здесь, могут иметь значение:

  • вычислительная мощность (ЦП)
  • рабочая память (ОЗУ)
  • Хранение данных
  • Пропускная способность сети

Как можно решить эти проблемы

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

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

Фрагмент кода

Найдите ниже очень упрощенный фрагмент кода. Точка 1 и точка 2 полностью независимы по своей природе, они могут даже находиться в разных потоках (на самом деле это идея, как это можно сделать, но я не достаточно хорошо понимаю многопоточность, чтобы решить, будет ли это хороший подход или нет). Действие начинается сначала, когда они привязаны к другому. Мне все равно, если поведение «сначала это, потом это» происходит определенным образом. Единственное, что меня волнует, это то, что все взаимодействия между этими двумя точками произошли в какой-то момент в будущем (после их прикрепления).

namespace Circularity
{
    class Program
    {
        static void Main(string[] args)
        {
            Point Point1 = new Point();
            Point Point2 = new Point();
            Point1.attach(Point2);
        }
    }
    class Point
    {
        private ulong Value;

        public Point()
        {
            Value = ulong.MaxValue / 2;
        }

        public void attach(Point otherPoint)
        {
            if (Value < ulong.MaxValue) Value++;
            otherPoint.attach(this);
        }
    }
}

Этот код мгновенно приводит к переполнению стека. Но я недостаточно хорошо понимаю основополагающие концепции стека, чтобы реализовать контрмеры. Я уже пытался применить концепцию Time, но для переполнения стека это занимает больше времени.

1 Ответ

2 голосов
/ 12 марта 2020

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

Когда и как использовать стиль передачи продолжения

...