Здравствуйте, Sinclair, Вы писали:

V>>Т.е. тот же исходник, с чуть другим форматированием и идентификаторами?
S>Примерно так.

Это слив корпоративного ноу-хау.


V>>Исследования имеющихся lock-free алгоритмов и потенциальных способов их применимости в наших сценариях я делал за зарплату в рабочее время когда-то.
V>>Туда же изобретение собственных как алгоритмов, так и сценариев их применения.
S>Вы же в курсе, что алгоритмы не являются охраноспособными?

Только на алгоритмы и можно получить патент.
Но на конкретную реализацию алгоритма (вотчина авторского права) патент получить нельзя.

Далее.
Патент требует раскрытия алгоритма.
Срок патента ограничен.
Ограничена географическая область патента — охрана действительна только в стране выдачи и в странах, где действуют взаимные патентные соглашения со страной выдачи.
Патенты стоят денег, патентировать алгоритмы по всему миру дорого.

Не зря в программировании прижилось в основном "ноу-хау" — коммерческая тайна.
А крупные конторы патентируют обычно вещи, которые видны невооружённым взглядом, т.е. алгоритмы работы системы в целом, на высоком уровне.

И то, я как-то почитывал такие патенты — удивлялся.
Похоже, патентируют очевидные вещи сугубо в кач-ве защиты от патентных троллей.
Этим информационным мусором отбили всякое любопытство почитывать западные патенты.


S>А исходный код — это исходный код. В него входит и форматирование, и идентификаторы. ГК РФ запросто разрешает параллельно разрабатывать два кода, один из которых является служебным произведением, а второй — нет.

Да плевать на тонкости реализации и форматирования. ))
Не уверен, что требуется кому-либо объяснять это.


V>>Например, у нас при банальной отсылке данных в сокет совместно работает сразу 3 lock-free алгоритма.
V>>Каждый из них простейший, но их определённая комбинация рождает новый алгоритм более высокого уровня, который умудряется быть тем эффективней, чем больше нагрузка.
S>Хорошо вам.

Там кейз специфический — lock-free очередь обслуживает так же примитив сигнализации, на котором надо ожидать в отсутствии задач или IO.

В дотнете же для тасков используют встроенный пул, который в случае Windows и вовсе системный:
https://docs.microsoft.com/en-us/windows/win32/api/threadpoollegacyapiset/nf-threadpoollegacyapiset-queueuserworkitem

И потоки из пула ожидают на внутренних своих примитивах сигнализации внутри WinaAPI, где нет возможности добавить знание о происходящем в очереди в сам факт манипулирования примитивами сигнализации.
Например, дотнет должен обслуживать как потенциально-легковесную очередь задач самому себе, так и поступающие извне в поток UserWorkItem, даже если они к Task не имеют никакого отношения.

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

Даже запрос текущего monotonic-системного времени был переосмыслен. ))
Кароч, всё то, что отжирало то тут, то там сотни наносекунд или даже до микросекунды на каждый чих, складываясь в общую задержку.
Стоимость своих альтернативных решений — единицы-десяки наносекунд на каждую такую операцию-кирпичик.


V>>Выглядит как "я хочу на блюдечке с голубой каёмочкой".
V>>Хотел бы по-настоящему, уже бы давал свои соображения по реализации (там есть на что обратить внимание).
S>Не, я не настолько квалифицирован в lock-free алгоритмах.

Ну, сложные lock-free алгоритмы не всегда в реальном использовании обгоняют простые на мьютексах, если блокировки мьютексов короткие и вероятность конфликтов низка.
По настоящему эффективными могут быть только предельно простые lock-free алгоритмы, их можно понять и без специальной подготовки.

Тогда задача перетекает в несколько другую плоскость — попытаться расписать работу всей системы на комбинации отдельных простых lock-free алгоритмов.
Для меня это неотъемлимый контекст по работе, с этих позиций и рассуждал.
Поэтому, нет желания прогибаться под попытку переиначить исходные мои заявления, вычленить и рассмотреть только часть и т.д.

Опять же, дотнетный пул потоков под таски обычно в разы больше кол-ва ядер в системе.
Я как-то замерял — на моих 12 ядрах он создавал под 200 с лишним потоков в пуле на интенсивном использовании.

Поэтому, потенциальное блокирование из-за того, что реализация конкурентной очереди не удовлетворяет гарантиям lock-free, что потенциально может заморозить лишь +1 попавший в конфликт поток — это вроде как приписанное системе допущение. И тогда очередь остальных задач к потоку может разгребаться другими потоками.
Но эта парочка задач-неудачниц будет страдать. ))

Совсем другое дело, когда в нашем пуле ровно столько потоков, сколько ядер, гарантии lock-free соблюдаются, ни один поток не морозится.
Таски, таймеры и IO обслуживаются в этом общем пуле, процессоры переключают контексты исполнения крайне редко — когда нет данных, т.е. можно уйти в спячку до получения сигнала о пробуждении.


V>>И да, замена очереди и переосмысливание всей системы в конце всех концов делает асинхронщину в разы эффективнее, например, как у нас.
S>Ну, вы молоцы. Жалко, что кроме вас, об этом никто не знает

Индустрия знает, мы в лидерах, 1-2-е места по репортам тестовых лабораторий Intel.

Или взять сугубо дотнет, у конкурентов https://www.b2bits.com/trading_solutions/fix_engines/fix_engine_net-core
50 тыс сообщений в сек, у нас что-то более полутора млн.

Т.е. разница где-то в 30-40 раз.
При этом сама наша асинхронщина быстрее всего-лишь раз в 17, т.е., эффективность надо набирать отовсюду, получая конечную её.
Никакое одно решение не даёт нормальной эффективности, это всегда большой комплекс мер.


V>>Ну, если фанаты будут обсуждать не технику игроков, а их одежду и даже стрижку вратаря — то где-то так и будет.
S>Так а как можно обсуждать технику, которой нет?

Можно обсуждать, какой она могла бы быть.
Тем более, что адрес одного из примеров был дан.


S>Нет кода — нет предмета обсуждения.

Слава богу, очень немногие коллеги так категорично ставят вопрос.
В основе всего лежит идея.
И даже не спорь. ))

"Дайте готовый код" — присказка уставших от жизни ленивцев.


S>Выходит так, что ваша часть дискуссии — это "ваш Месси плохо держит мяч, у меня есть игрок, который делает это лучше. Но я вам его не покажу, потому что он секретный. И вообще — есть множество других игроков, вполне публичных, которые играют лучше Месси. Но я вам их не назову — сами найдите да посмотрите".

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


S>Предлагаю тему свернуть, потому как про воображаемый секретный код мне не очень интересно.

А как другой код поможет тебе понять, что именно происходит в дотнетных тасках сейчас?
Чем тебя не устраивает уже имеющийся дотнетный код для целей анализа происходящего?
Не интересно? (скорее всего)

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