Я могу сказать как определился с синглтонами я.
Я пользуюсь синглтонами. Но чтобы ограничить скоуп, я назначаю ссылку на instance в конструкторе самого синглтона, а сам синглтон создаю где-то в мэйне. Это даёт 1) возможность управлять порядком инициализации синглтонов, в том числе если какие-то из них вдруг зависят друг от друга. 2) возможность управлять порядком их разрушения (полезно например в С++), ну и 3) стандартная возможность синглтонов — доступ из любого места кода.
Иными словами синглтон не создаётся по запросу instance, а создаётся как обычный объект, разница только в том что создаться может лишь один экземпляр, и доступ к нему может быть отовсюду.
Реальные конкретные числа, замеры, указаны в конце статьи =)
Озвученный в статье подход даёт почти 30% прироста в сравнении с чистым lock-free или чистым спинлоком.
«Если требуется атомарная обработка блоков данных, объёмами в несколько десятков мегабайт, то использование мьютексов было бы намного эффективнее.»
Это очень зависит от того насколько трудоёмка функция обработки данных. Если копирование намного быстрее, то скорее всего более эффективно будет скопировать и освободить указатель.
И в любом случае флажки-спинлоки в 99% случаев более эффективны нежели мьютексы.
Прошу прощения, действительно проблема 1 неактуальна. Но остаётся всё же 2 и 3. Оверхед на поддержку очередей с лихвой перекроет любой возможный прирост быстродействия. Не представляю, как вы собираетесь решать проблему пустой очереди с помощью фейкового элемента.
А вы, батенька, оптимист =)
В любой структуре данных, даже в очереди, бывают следующие случаи:
1) несколько потоков пишут или читают в/из очереди одновременно (это уже не входит в вашу концепцию)
2) очередь содержит 0 или 1 элемент, в данном случае при чтении/записи доступ идёт к одному и тому же элементу: head == tail
все эти случаи тоже нуждаются в грамотной обработке. Это возможно только с помощью локов, или тех же самых атомарных доступов.
Ну и плюс ваш подход съедает нехилое количество инструкций только на арбитраж.
Я надеюсь вы до конца прочитали? Нет, это не перевод и не пересказ. Более того, в конце статьи делаются выводы о нецелесообразности использования чистого лок-фри подхода в применении к стеку.
Видите ли, иногда то, чему учат в ВУЗах необходимо переосмысливать. Если вы понимаете, зачем существует это правило, значит вы поймёте, почему в данном случае им можно пренебречь.
Попробуйте в следующий раз вместо «каждый начинающий олимпиадник» подобрать какое-нибудь более нейтральное обращение, и Вы удивитесь, насколько больше стали прислушиваться к вашим словам.
Если вы внимательно посмотрите на свой алгоритм, вы поймете, что он не отличает точку лежащую на отрезке и точку, лежащую на прямой, но не на отрезке. Эту разницу просто нельзя вычислить векторными произведениями, которые всегда нулевые, если все лежит на одной прямой.
Ну собственно поэтому я Вам и ответил, что я не учитывал случай отрезков лежащих на одной прямой. Во всех остальных случаях данный алгоритм работать будет.
Ну строго говоря он внезапно лежит на любой прямой проходящей через конечные(ную) точки(ку) нулевого отрезка. Поэтому такая конфигурация подходит под условие и той задачи которая ставилась мне.
Ну и я не вижу, чем решение системы уравнений проще двух векторных произведений.
В плане совпадающих отрезков я Вас услышал. Действительно, я лично не уверен, как их классифицировать. В моём случае стояла задача о пересечении отрезков двух различных прямых, но в общем случае Вы правы.
В наше время нельзя критиковать законы. Васю, впрочем, тоже нельзя. Поэтому мы будем критиковать мессенджер.
В 2025 году ты не можешь быть уверенным, что ты законопослушный гражданин, даже если ты ничего не делаешь.
Я пользуюсь синглтонами. Но чтобы ограничить скоуп, я назначаю ссылку на instance в конструкторе самого синглтона, а сам синглтон создаю где-то в мэйне. Это даёт 1) возможность управлять порядком инициализации синглтонов, в том числе если какие-то из них вдруг зависят друг от друга. 2) возможность управлять порядком их разрушения (полезно например в С++), ну и 3) стандартная возможность синглтонов — доступ из любого места кода.
Иными словами синглтон не создаётся по запросу instance, а создаётся как обычный объект, разница только в том что создаться может лишь один экземпляр, и доступ к нему может быть отовсюду.
Озвученный в статье подход даёт почти 30% прироста в сравнении с чистым lock-free или чистым спинлоком.
Это очень зависит от того насколько трудоёмка функция обработки данных. Если копирование намного быстрее, то скорее всего более эффективно будет скопировать и освободить указатель.
И в любом случае флажки-спинлоки в 99% случаев более эффективны нежели мьютексы.
В любой структуре данных, даже в очереди, бывают следующие случаи:
1) несколько потоков пишут или читают в/из очереди одновременно (это уже не входит в вашу концепцию)
2) очередь содержит 0 или 1 элемент, в данном случае при чтении/записи доступ идёт к одному и тому же элементу: head == tail
все эти случаи тоже нуждаются в грамотной обработке. Это возможно только с помощью локов, или тех же самых атомарных доступов.
Ну и плюс ваш подход съедает нехилое количество инструкций только на арбитраж.
Ну собственно поэтому я Вам и ответил, что я не учитывал случай отрезков лежащих на одной прямой. Во всех остальных случаях данный алгоритм работать будет.
Ну и я не вижу, чем решение системы уравнений проще двух векторных произведений.
И, вот, вопрос к вам возник. Является ли пересечением отрезок нулевой длины лежащий на другом отрезке?
Нашёл указанный Вами алгоритм в главе 35.
Однако в алгоритме у Кормена никак не находится точка пересечения прямых.