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

V>>Это называется заблудиться в трёх соснах. ))
V>>Я уже подсказал, где можно найти аналогичную реализацию очереди, свой исходник вряд ли имею право дать.
S>Смешно. Сделайте другой исходник.

Т.е. тот же исходник, с чуть другим форматированием и идентификаторами?
Действительно, смешно.


S>ГК РФ запрещает относить к служебным произведениям что-то, сделанное вне рамок должностных обязанностей или распоряжений руководства.

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

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

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


V>>(да и смысла нет, если аналог доступен в открытом доступе)
S>Обожаю смотреть, как вы начинаете вертеться, как только речь заходит о реальном коде.

И это при выданных координатах аналогичного кода?
Выглядит как "я хочу на блюдечке с голубой каёмочкой".
Хотел бы по-настоящему, уже бы давал свои соображения по реализации (там есть на что обратить внимание).


V>>И что было непонятного в том замечении, что очередь с той дисциплиной потребует переписать механизм тасков?
V>>Это попытка замылить суть вопроса или что?
S> От критиков ConcurrentQueue не требуется переписать механизм тасков.

Ну не демагогам же это решать?
Невозможно свести совокупность высказанных мною претензий к простому "критика ConcurrentQueue".
Слишком грубая подмена тезиса.


S>Если очередь плоха сама по себе — то её можно заменить на ту очередь, которая хорошая сама по себе.

Абстрактного коня в вакууме заменить на абстрактного верблюда в вакууме?

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

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


S>То, что в реализации механизма тасков используется не лучшая реализация очереди для механизма тасков — ортогональный вопрос.

На пальцах показываешь как работает приём "подмена тезиса"?


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

Можно.
Их поиск будет стоить мне столько же трудоёмкости, сколько и тебе.


S>Ну, и убедительно продемонстрировать разницу между "плохим" вариантом и "хорошим" вариантом.

Разница в разы эффективности системы в целом, как throughput, так и latency.
Причём, в дотнетной же реализации, которая калька с плюсовой, но отстаёт от плюсовой совсем немного, что малость неожиданно.

Но у нас еще присутствует уникальная lock-free реализация самого task объекта (пара promise-future в терминах С++, перетащилии в дотнет), чего в майкрософтных PPL нет.
И нигде сегодня нет.
Я специально много искал — глухо, везде блокирующие алгоритмы у альтернативных реализаций future-подобных объектов.


S>Без этого вся дискуссия — споры футбольных фанатов.

Ну, если фанаты будут обсуждать не технику игроков, а их одежду и даже стрижку вратаря — то где-то так и будет.
Мода ветренна, пристрастия ненадёжны.

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

V>>Это называется заблудиться в трёх соснах. ))
V>>Я уже подсказал, где можно найти аналогичную реализацию очереди, свой исходник вряд ли имею право дать.
S>Смешно. Сделайте другой исходник.

Т.е. тот же исходник, с чуть другим форматированием и идентификаторами?
Действительно, смешно.


S>ГК РФ запрещает относить к служебным произведениям что-то, сделанное вне рамок должностных обязанностей или распоряжений руководства.

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

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

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


V>>(да и смысла нет, если аналог доступен в открытом доступе)
S>Обожаю смотреть, как вы начинаете вертеться, как только речь заходит о реальном коде.

И это при выданных координатах аналогичного кода?
Выглядит как "я хочу на блюдечке с голубой каёмочкой".
Хотел бы по-настоящему, уже бы давал свои соображения по реализации (там есть на что обратить внимание).


V>>И что было непонятного в том замечении, что очередь с той дисциплиной потребует переписать механизм тасков?
V>>Это попытка замылить суть вопроса или что?
S> От критиков ConcurrentQueue не требуется переписать механизм тасков.

Ну не демагогам же это решать?
Невозможно свести совокупность высказанных мною претензий к простому "критика ConcurrentQueue".
Слишком грубая подмена тезиса.


S>Если очередь плоха сама по себе — то её можно заменить на ту очередь, которая хорошая сама по себе.

Абстрактного коня в вакууме заменить на абстрактного верблюда в вакууме?

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

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


S>То, что в реализации механизма тасков используется не лучшая реализация очереди для механизма тасков — ортогональный вопрос.

На пальцах показываешь как работает приём "подмена тезиса"?


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

Можно.
Их поиск будет стоить мне столько же трудоёмкости, сколько и тебе.


S>Ну, и убедительно продемонстрировать разницу между "плохим" вариантом и "хорошим" вариантом.

Разница в разы эффективности системы в целом, как throughput, так и latency.
Причём, в дотнетной же реализации, которая калька с плюсовой, но отстаёт от плюсовой совсем немного, что малость неожиданно.

Но у нас еще присутствует уникальная lock-free реализация самого task объекта (пара promise-future в терминах С++, перетащили и в дотнет), чего в майкрософтных PPL нет.
И нигде сегодня нет.
Я специально много искал — глухо, везде блокирующие алгоритмы у альтернативных реализаций future-подобных объектов.


S>Без этого вся дискуссия — споры футбольных фанатов.

Ну, если фанаты будут обсуждать не технику игроков, а их одежду и даже стрижку вратаря — то где-то так и будет.
Мода ветренна, пристрастия ненадёжны.