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

V>>Или крайне простой велосипед — очередь.
V>>Это зависит от способа представления вычислительных задач.
S>Можно обсудить оба способа.

Строго говоря, оба раза способ примерно один и тот же (с точностью до подробностей реализации).

Вопрос больше в том, кто занимается раздачей управления выч.задачам — операционка или юзверский (по отношению к операционке) код.


V>>Собсно, поэтому, если стоит задача разработки системы сложных блокировок, то опираться на даваемые операционкой ср-ва стоит с осторожностью, т.е. следует учитывать/измерять, насколько ср-ва ОС адекватны решаемой задаче. В обсуждаемой предметной области серверных приложений — неадекватны.
S>Ок, зачем тогда вы их начали обсуждать?

Странный вопрос.
При анализе проблематики обычно сначала рассматриваются уже имеющиеся способы решения (если есть), выясняется степень их подходящести под условия задачи и т.д.

Контекст как бэ предполагался известным, но учитывая странную реакцию на "самописные мьютексы" (C), я счёл нужным оговориться — зачем "самописные".


S>Предлагаете заведомо неадекватное решение, да ещё и неполное?

Какое именно неадекватное решение я предлагал и почему оно неполное-то? ))

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

Например (опять про очереди) классическая межпоточная очередь на условной переменной сливает самописной моей реализации на комбинации lock-free алгоритмов и примитива синхронизации ОС (когда-то же потоку-приёмнику в спячку уходить надо в отсутствии задач) где-то под 50 раз в тестах пропускной способности.

Поэтому я рассуждал об адекватности (т.е. соответствии) встроенных ср-в ОС задачам нетривиальной диспетчеризации данных и задач.

А ты, насколько я заметил, вместо рассуждений о соотвествии встроенных ср-в ОС задачам обыгрывания нетривиальных иерархий блокировок, рассуждаешь "там всё сложно" (С).

Сложного там ничего нет.
Ты многократно показывал решения куда как более сложных задач, я ж всё смотрю, во всё вникаю (иногда такое ощущение — что единственный на этом сайте, бгг).

Вот я и стебусь здесь, что у тебя как эдакая ломка, сугубо из-за того, что ранее тебе не приходилось решать задачи из этого направления.

==========
Остальное дочитаю и отвечу потом, пока мест в этом посте ничего вызывающего не встретилось. )

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

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

Вот как выше — ты задал сразу пачку вопросов не по существу. Но отвечать же что-то надо? ))

Когда/если будешь "упражняться" — стоит держать в голове, что блокировки не цель, но лишь способ упорядочивания изначально хаотичного конкурентного трафика заявок.
Т.е. целью является именно диспетчеризация заявок, где "блокировки" — вспомогательный механизм.

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

V>>Или крайне простой велосипед — очередь.
V>>Это зависит от способа представления вычислительных задач.
S>Можно обсудить оба способа.

Строго говоря, оба раза способ примерно один и тот же (с точностью до подробностей реализации).

Вопрос больше в том, кто занимается раздачей управления выч.задачам — операционка или юзверский (по отношению к операционке) код.


V>>Собсно, поэтому, если стоит задача разработки системы сложных блокировок, то опираться на даваемые операционкой ср-ва стоит с осторожностью, т.е. следует учитывать/измерять, насколько ср-ва ОС адекватны решаемой задаче. В обсуждаемой предметной области серверных приложений — неадекватны.
S>Ок, зачем тогда вы их начали обсуждать?

Странный вопрос.
При анализе проблематики обычно сначала рассматриваются уже имеющиеся способы решения (если есть), выясняется степень их подходящести под условия задачи и т.д.

Контекст как бэ предполагался известным, но учитывая странную реакцию на "самописные мьютексы" (C), я счёл нужным оговориться — зачем "самописные".


S>Предлагаете заведомо неадекватное решение, да ещё и неполное?

Какое именно неадекватное решение я предлагал и почему оно неполное-то? ))

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

Например (опять про очереди) классическая межпоточная очередь на условной переменной сливает самописной моей реализации на комбинации lock-free алгоритмов и примитива синхронизации ОС (когда-то же потоку-приёмнику в спячку уходить надо в отсутствии задач) где-то под 50 раз в тестах пропускной способности.

Поэтому я рассуждал об адекватности (т.е. соответствии) встроенных ср-в ОС задачам нетривиальной диспетчеризации данных и задач.

А ты, насколько я заметил, вместо рассуждений о соотвествии встроенных ср-в ОС задачам обыгрывания нетривиальных иерархий блокировок, рассуждаешь "там всё сложно" (С).

Сложного там ничего нет.
Ты многократно показывал решения куда как более сложных задач, я ж всё смотрю, во всё вникаю (иногда такое ощущение — что единственный на этом сайте, бгг).

Вот я и стебусь здесь, что у тебя как эдакая ломка, сугубо из-за того, что ранее тебе не приходилось решать задачи из этого направления.

==========
Остальное дочитаю и отвечу потом, пока мест в этом посте ничего вызывающего не встретилось. )

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

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

Вот как выше — ты задал сразу пачку вопросов не по существу. Но отвечать же что-то надо? ))

Когда/если будешь "упражняться" — стоит держать в голове, что блокировки не цель, но лишь способ упорядочивания изначально хаотичного конкурентного трафика заявок.
Т.е. целью является именно диспетчеризация заявок, где "блокировки" — вспомогательный механизм.