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

[]

КЛ>>с чего это он провалится, если в момент прохода мы имеем консистентные на 100% данные?

R>Ты путаешь причину и следствие. Он не провалится, если мы имеем 100% консистентные данные. Но то, что мы их имеем не факт. Это будет факт только если STM реализована через один глобальный мьютекс. Тогда каждая операция будет 100% удаваться, но это определенно не то, что мы хотим.

что значит не факт. это по определению мы имеем 100% конс. данные


R>

Здравствуйте, Константин Л., Вы писали:

КЛ>Здравствуйте, remark, Вы писали:

КЛ>[]

КЛ>>>с чего это он провалится, если в момент прохода мы имеем консистентные на 100% данные?

R>>Ты путаешь причину и следствие. Он не провалится, если мы имеем 100% консистентные данные. Но то, что мы их имеем не факт. Это будет факт только если STM реализована через один глобальный мьютекс. Тогда каждая операция будет 100% удаваться, но это определенно не то, что мы хотим.

КЛ>что значит не факт. это по определению мы имеем 100% конс. данные...

... возможно после нескольких повторов операции, когда мы видели не консистентные данные.

Т.е. с т.з. пользователя — да, транзакция как-будто всегда видит консистентные данные. Но сколько перед этим было перезапусков транзакции, когда был детектирован конфликт, не определено.

R>>

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

R>Плюс ещё "жалко" остальную команду, они ещё от Егорушкина отходят, а тут ещё я со своими lock-free алгоритмами. Поэтому я стараюсь держать всё в рамках приличия :)))

Это Егорушкин от нас отходит, причем куда-то очень далеко.

А чем таким он знаменит? Он вроде только про C++ писал, в один поток ;-)?

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

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

R>>Плюс ещё "жалко" остальную команду, они ещё от Егорушкина отходят, а тут ещё я со своими lock-free алгоритмами. Поэтому я стараюсь держать всё в рамках приличия

RO>Это Егорушкин от нас отходит, причем куда-то очень далеко.

RO>А чем таким он знаменит? Он вроде только про C++ писал, в один поток ?

Ну так от его С++ и отходят

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

R>При этом, как ты правильно заметил, для некоторых структур данных работа на основе обмена сообщениями будет очень неэффективной.
Вот это место у меня вызывает сомнения.
R> Во-первых, резко повышается латентность операций — вместо прямого обращения к разделяемой структуре, нам теперь надо отправить сообщение, другой поток "когда-то" его достанет из очереди, обработает, отправит ответ, потом исходный поток опять "когда-то" достанет ответ из очереди и продолжит обработку.
Ок, а какая, простите, была альтернатива? Поток 1 захватывает мьютекс, пишет в разделяемую структуру, отдает мьютекс, выставляет event и начинает ждать второго евента.
В хорошем случае Поток 2 уже спит в ожидании евента и просыпается более-менее сразу. В более плохом он в это время чем-то занят, и только когда-то в будущем выполнит WaitFor, чтобы узнать о приходе данных. В обратную сторону имеем ту же ситуацию.
R>Во-вторых, стоимость тоже не очевидна, т.к. каждая операция с сообщением — это обращение к разделяемой структуре данных, а у нас тут получается 4 таких операции.
Так ведь как раз вся фишка ровно в том, что сообщения — не разделяемые структуры данных! Поэтому там, где надо было жонглировать мьютексами, теперь достаточно прямого доступа.
Основная прелесть системы обмена сообщениями — в том, что есть шанс применить escape-analysis. Если поток 1 больше не выполняет операций над сообщением, то можно обойтись безо всякого копирования, и просто разрешить потоку 2 работать с той же разделяемой структурой напрямую без синхронизации.

Это как СУБД, которая заранее знает, нужно ли захватывать блокировки или эти данные всё равно никто не увидит.

R>В третьих, если это центральная структура данных, и при этом с ней напрямую может работать только один поток, а остальные только с помощью сообщений, то получается, что у нас фактически производительность системы ограничена производительностью одного потока.
R>Представь, например, 32-ух процессорную систему, на которой все процессоры обязаны постоянно обращаться к одному — 31 процессор будет большую часть времени простаивать.
Ты описываешь просто реализацию мьютекса через очередь сообщений. Естественно мы получим гарантию хреновой производительности в таком случае: мьютекс собственно и гарантирует то, что не более 1го потока выполняют прикрытую им работу. Для того, чтобы message-oriented cистемы работали, нужно размазать данные по очередям.
Это не то чтобы как-то очень сложно; это просто другой способ декомпозиции задачи. Ну вот представь себе, что ты разрабатываешь банальный SMTP Relay. Если ты — ООПшник, то у тебя там будет в памяти некоторый контейнер "очередь сообщений", в него будут добавлять мессаги потоки, обрабатывающие клиентов, и выгребать мессаги потоки, обрабатывающие доставку. Ты будешь тренироваться в обеспечении синхронизации, выбирая правильную гранулярность, чтобы не более одного потока пытались доставить некоторое сообщение и т.п. Этот контейнер может оказаться bottleneck-ом (в данном случае этого конечно же не случится, т.к. типичные времена доставки одного почтового сообщения в миллиарды раз выше расходов на синхронизацию, но для примера сойдет).
В message-oriented системе тебе вообще не нужен этот контейнер в явном виде. Один поток принял письмо от клиента — кинул его другому для отправки. Тот получил — выполнил попытку — если она не удалась, перекинул в поток ожидания, который тупо задержит форвард письма на, скажем 3600 секунд. И так далее.

R>Исходя из всего этого я лично считаю, что системы типа Eralng (основанные исключительно на обмене сообщениями) сливают в общем случае.
R>Тут целесообразно *некоторые* структуры реализовать именно как многопоточные разделяемые модифицируемые структуры, сделав реализацию оптимальную под данную задачу.

R>Что касается реализации.
R>Очереди типа single-producer/single-consumer можно реализовать экстремально эффективно без использования ни мьютексов, ни TM. В такой реализации каждая операция (enqueue/dequeue) занимает не более 10 машинных инструкций и не содержит никаких тяжёлых операций, типа InterlockedXXX или тяжёлых барьеров памяти. Бенчмарки такой очереди против реализаций на основе мьютексов, TM, InterlockedXXX похожи на кровопролитное массовое убийство невинных детей. Это единственный верный путь.
Вот я так понимаю, что продвинутая среда может опознавать очереди такого типа при помощи статического анализа, и получать офигительное быстродействие. Главная забота разработчика — следить, чтобы таких очередей было побольше.

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

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

R>>При этом, как ты правильно заметил, для некоторых структур данных работа на основе обмена сообщениями будет очень неэффективной.

S>Вот это место у меня вызывает сомнения.

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

S>Ок, а какая, простите, была альтернатива? Поток 1 захватывает мьютекс, пишет в разделяемую структуру, отдает мьютекс, выставляет event и начинает ждать второго евента.
S>В хорошем случае Поток 2 уже спит в ожидании евента и просыпается более-менее сразу. В более плохом он в это время чем-то занят, и только когда-то в будущем выполнит WaitFor, чтобы узнать о приходе данных. В обратную сторону имеем ту же ситуацию.


Я рассматривал 2 следующие альтернативы.
Допустим у нас есть список неких данных, и потоку надо, например, произвести поиск по ключу и вернуть связанные с ключом данные.
Вариант 1. Используется lock-based/lock-free/STM/что-то-ещё структура данных и поток напрямую обращается к структуре и производит необходимые действия и получает результат.
Вариант 2. Поток посылает сообщение-запрос другому потоку, который "владеет" структурой. Тот поток обрабатывает сообщение, обращаясь к структуре в "однопоточном" режиме, и посылает сообщение-ответ исходному потоку.

В первом вариант нет ожиданий между потоками.


R>>Во-вторых, стоимость тоже не очевидна, т.к. каждая операция с сообщением — это обращение к разделяемой структуре данных, а у нас тут получается 4 таких операции.

S>Так ведь как раз вся фишка ровно в том, что сообщения — не разделяемые структуры данных! Поэтому там, где надо было жонглировать мьютексами, теперь достаточно прямого доступа.


Но очереди-то — разделяемые структуры данных. А во втором варианте получается 4 обращения к очередям.

Плюс данные сообщения, они хоть и не разделяемые, но они *передаются* между потоками. Т.е. они требуют "межядерного" трафика данных. Это тоже имеет ощутимую цену.


S>Основная прелесть системы обмена сообщениями — в том, что есть шанс применить escape-analysis. Если поток 1 больше не выполняет операций над сообщением, то можно обойтись безо всякого копирования, и просто разрешить потоку 2 работать с той же разделяемой структурой напрямую без синхронизации.

S>Это как СУБД, которая заранее знает, нужно ли захватывать блокировки или эти данные всё равно никто не увидит.


Я сейчас в С++ отлавливаю следующие ситуации:

post_msg(my_msg::create(1, 2, 3));

create() создаёт сообщение сразу со счетчиком 1. post_msg() видит, что ему передают временный объект и *крадёт* значение счетчика ссылок, т.е. сам не инкрементирует когда кладёт в очередь. Ну на принимающей стороне ещё проще — после обработки видим, что счётчик ссылок равен 1, и сразу удаляем объект.
Т.е. с помощью такого "псевдо escape анализа" и трюка при декременте, получается устранить все операции со счётчиком ссылок. Хотя в общем случае они поддерживаются — т.е. один поток может послать одно сообщение 10 потокам, а те ещё переслать и т.д.

С escape анализом, безусловно можно будет делать более интересные вещи — например разрулить вот это:

msg m = my_msg::create(1, 2, 3);
post_msg(m);

Хотя я, честно говоря, не в курсе что сейчас может escape анализ в Java/C#. Но мне кажется, что если речь идёт о нескольких функциях, то он сдаёт позиции.

Но повторюсь, что это не снимает момента о том, очереди — разделяемые структуры данных, и о том, что данные сообщения надо физически передавать между ядрами/процессорами.

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


R>>В третьих, если это центральная структура данных, и при этом с ней напрямую может работать только один поток, а остальные только с помощью сообщений, то получается, что у нас фактически производительность системы ограничена производительностью одного потока.
R>>Представь, например, 32-ух процессорную систему, на которой все процессоры обязаны постоянно обращаться к одному — 31 процессор будет большую часть времени простаивать.

S>Ты описываешь просто реализацию мьютекса через очередь сообщений. Естественно мы получим гарантию хреновой производительности в таком случае: мьютекс собственно и гарантирует то, что не более 1го потока выполняют прикрытую им работу. Для того, чтобы message-oriented cистемы работали, нужно размазать данные по очередям.
S>Это не то чтобы как-то очень сложно; это просто другой способ декомпозиции задачи. Ну вот представь себе, что ты разрабатываешь банальный SMTP Relay. Если ты — ООПшник, то у тебя там будет в памяти некоторый контейнер "очередь сообщений", в него будут добавлять мессаги потоки, обрабатывающие клиентов, и выгребать мессаги потоки, обрабатывающие доставку. Ты будешь тренироваться в обеспечении синхронизации, выбирая правильную гранулярность, чтобы не более одного потока пытались доставить некоторое сообщение и т.п. Этот контейнер может оказаться bottleneck-ом (в данном случае этого конечно же не случится, т.к. типичные времена доставки одного почтового сообщения в миллиарды раз выше расходов на синхронизацию, но для примера сойдет).
S>В message-oriented системе тебе вообще не нужен этот контейнер в явном виде. Один поток принял письмо от клиента — кинул его другому для отправки. Тот получил — выполнил попытку — если она не удалась, перекинул в поток ожидания, который тупо задержит форвард письма на, скажем 3600 секунд. И так далее.


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


R>>Исходя из всего этого я лично считаю, что системы типа Eralng (основанные исключительно на обмене сообщениями) сливают в общем случае.
R>>Тут целесообразно *некоторые* структуры реализовать именно как многопоточные разделяемые модифицируемые структуры, сделав реализацию оптимальную под данную задачу.

R>>Что касается реализации.
R>>Очереди типа single-producer/single-consumer можно реализовать экстремально эффективно без использования ни мьютексов, ни TM. В такой реализации каждая операция (enqueue/dequeue) занимает не более 10 машинных инструкций и не содержит никаких тяжёлых операций, типа InterlockedXXX или тяжёлых барьеров памяти. Бенчмарки такой очереди против реализаций на основе мьютексов, TM, InterlockedXXX похожи на кровопролитное массовое убийство невинных детей. Это единственный верный путь.

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

Я правильно понимаю, что ты говоришь о ситуации, когда потоку посылает сообщения только один другой поток? Я не думаю, что детектирование таких вещей возможно в ближайшем будущем...
Тем более тут вопрос больше не оптимизации, а дизайна. Т.к. одну multi-producer/multi-consumer очередь всегда можно заменить на N multi-producer/single-consumer, или на N^2 single-producer/single-consumer.

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

R>Я рассматривал 2 следующие альтернативы.
R>Допустим у нас есть список неких данных, и потоку надо, например, произвести поиск по ключу и вернуть связанные с ключом данные.
R>Вариант 1. Используется lock-based/lock-free/STM/что-то-ещё структура данных и поток напрямую обращается к структуре и производит необходимые действия и получает результат.
R>Вариант 2. Поток посылает сообщение-запрос другому потоку, который "владеет" структурой. Тот поток обрабатывает сообщение, обращаясь к структуре в "однопоточном" режиме, и посылает сообщение-ответ исходному потоку.
Вариант 3. Используется read-only структура, доступ к которой осуществляется без блокировок. Все модификации порождают новую структуру , и она атомарно заменяет старую.
R>В первом вариант нет ожиданий между потоками.


R>Но очереди-то — разделяемые структуры данных. А во втором варианте получается 4 обращения к очередям.
Да, к двум однонаправленным очередям того самого типа single producer — single consumer. Что, как ты сам написал, позволяет рассматривать вариант 1 как "кровопролитное массовое убийство невинных детей".
R>Плюс данные сообщения, они хоть и не разделяемые, но они *передаются* между потоками. Т.е. они требуют "межядерного" трафика данных. Это тоже имеет ощутимую цену.
Не вполне понятно. Ты имеешь в виду исполнение потока 2 на другом ядре с независимым кэшем? Ну, в таком случае я не могу себе представить никакого бесплатного способа обменяться данными. В остальном непонятно: я так понял, что в управляемой среде с программной изоляцией никакого копирования данных не происходит. Просто указатель на данные попадает в код потока 2.

R>Я сейчас в С++ отлавливаю следующие ситуации:
R>

R>post_msg(my_msg::create(1, 2, 3));
R>

R>create() создаёт сообщение сразу со счетчиком 1. post_msg() видит, что ему передают временный объект и *крадёт* значение счетчика ссылок, т.е. сам не инкрементирует когда кладёт в очередь. Ну на принимающей стороне ещё проще — после обработки видим, что счётчик ссылок равен 1, и сразу удаляем объект.
R>Т.е. с помощью такого "псевдо escape анализа" и трюка при декременте, получается устранить все операции со счётчиком ссылок. Хотя в общем случае они поддерживаются — т.е. один поток может послать одно сообщение 10 потокам, а те ещё переслать и т.д.

R>С escape анализом, безусловно можно будет делать более интересные вещи — например разрулить вот это:
R>

R>msg m = my_msg::create(1, 2, 3);
R>post_msg(m);
R>

R>Хотя я, честно говоря, не в курсе что сейчас может escape анализ в Java/C#. Но мне кажется, что если речь идёт о нескольких функциях, то он сдаёт позиции.
Нет, конечно же в Java/C# escape анализ мало полезен.
Его нужно применять в других языках, которые построены на message passing. Вот, к примеру, Comega мог применять такие оптимизации — потому что у него нет таких вещей как post_msg; там просто вызов аккорда имеет семантику передачи сообщения. И компилятор видит весь код, который эти пользуется, и вполне может статически понять, сколько там producers у аккорда
R>Но повторюсь, что это не снимает момента о том, очереди — разделяемые структуры данных, и о том, что данные сообщения надо физически передавать между ядрами/процессорами.
Угу.

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

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

R>>Я рассматривал 2 следующие альтернативы.
R>>Допустим у нас есть список неких данных, и потоку надо, например, произвести поиск по ключу и вернуть связанные с ключом данные.
R>>Вариант 1. Используется lock-based/lock-free/STM/что-то-ещё структура данных и поток напрямую обращается к структуре и производит необходимые действия и получает результат.
R>>Вариант 2. Поток посылает сообщение-запрос другому потоку, который "владеет" структурой. Тот поток обрабатывает сообщение, обращаясь к структуре в "однопоточном" режиме, и посылает сообщение-ответ исходному потоку.

S>Вариант 3. Используется read-only структура, доступ к которой осуществляется без блокировок. Все модификации порождают новую структуру , и она атомарно заменяет старую.

Если такой способ можно применить, то замечательно. Для read-mostly данных — это очень хороший способ.
Но приложения обычно имеют и какие-то "активные" данные, которые постоянно изменяются. Например, список сессий, в который постоянно добавляются записи, удаляются, и ищутся. Тут не особо покопируешь, если структура данных не совсем маленькая.


R>>Но очереди-то — разделяемые структуры данных. А во втором варианте получается 4 обращения к очередям.

S>Да, к двум однонаправленным очередям того самого типа single producer — single consumer. Что, как ты сам написал,
позволяет рассматривать вариант 1 как "кровопролитное массовое убийство невинных детей".

Если используются такие очереди, то замечательно. Но и с ними связаны некоторые проблемы. Например, что бы иметь полно-связанную систему, таких очередей надо иметь уже N^2. Плюс в некоторых ситуациях прибавляется необходимость ручного load-balancing'а.
Даже если мы всё это решили, то задержка передачи 2 сообщений и стоимость физической передачи данных никуда не деваются.

Вобщем что я хочу сказать, что можно представить достаточно реалистичные примеры ситуаций, когда решение по варианту (1) будет обладать и большей пропускной способность и меньшей задержкой, чем решение по варианту (2).



R>>Плюс данные сообщения, они хоть и не разделяемые, но они *передаются* между потоками. Т.е. они требуют "межядерного" трафика данных. Это тоже имеет ощутимую цену.

S>Не вполне понятно. Ты имеешь в виду исполнение потока 2 на другом ядре с независимым кэшем? Ну, в таком случае я не могу себе представить никакого бесплатного способа обменяться данными.

Да, именно это. Бесплатный способ обмена сообщениями — не обмениваться сообщениями


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


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

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

R>Хорошо. Допустим нам надо добавить в эту систему спам фильтр, или антивирусную проверку, или рейтинги какие-то, или проверку орфографии, ну короче не важно, важно то, что у нас появляется большой массив каких-то данных, настолько большой, что реплицировать его не вариант, плюс он изменяется в течение времени. И нам надо делать обработку каждого сообщения используя данные их этого массива. Мы делаем на основе передачи сообщений, т.е. ни с какими мьютексами мы связываться не хотим, хотим сделать "однопоточную" реализацию массива данных.
R>Как ты предлагаешь это реализовать?
Это не интересная задача.
Делается это так:
Есть один процесс который принимает TCP/IP (или аналог) соединение.
Далие тупо ссоздает еще один процесс которому передает это соединение.
Это очень быстрый цикл.

Ессно ели у нас продвинутая ОС. (Потомок сингулярити.)

Далее процесс который получил соединение зачитывает письмо и кладет его в надежное хранилище. Ибо письма терять нельзя.

Теперь можно проверить письмо на спам, вирусы итп
В данном случае висит менеджер проверки на спам и смотрит чтобы одновременно проверяли не больше N писем на спам.
Менеджер антивируса следит чтобды проверяли не больше M писем на вирусы итп.
Результат складываем рядом с письмом.

Короче накладные расходы на кешь процессора ты тут никогда не увидишь.

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

Еще шедуллер ОС может отслеживать концы SP/SC очередей у процесса и держать его поближе к партнерам.

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

R>Тем более тут вопрос больше не оптимизации, а дизайна. Т.к. одну multi-producer/multi-consumer очередь всегда можно заменить на N multi-producer/single-consumer, или на N^2 single-producer/single-consumer.
MP/MC при наличии дешовых процессов ваще изврат.
MP/SC плюс процесс который спанит воркеров куда как эффективнее и надежнее.

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

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

R>>Хорошо. Допустим нам надо добавить в эту систему спам фильтр, или антивирусную проверку, или рейтинги какие-то, или проверку орфографии, ну короче не важно, важно то, что у нас появляется большой массив каких-то данных, настолько большой, что реплицировать его не вариант, плюс он изменяется в течение времени. И нам надо делать обработку каждого сообщения используя данные их этого массива. Мы делаем на основе передачи сообщений, т.е. ни с какими мьютексами мы связываться не хотим, хотим сделать "однопоточную" реализацию массива данных.
R>>Как ты предлагаешь это реализовать?
WH>Это не интересная задача.
WH>Делается это так:
WH>Есть один процесс который принимает TCP/IP (или аналог) соединение.
WH>Далие тупо ссоздает еще один процесс которому передает это соединение.
WH>Это очень быстрый цикл.

WH>Ессно ели у нас продвинутая ОС. (Потомок сингулярити.)

WH>Далее процесс который получил соединение зачитывает письмо и кладет его в надежное хранилище. Ибо письма терять нельзя.

WH>Теперь можно проверить письмо на спам, вирусы итп
WH>В данном случае висит менеджер проверки на спам и смотрит чтобы одновременно проверяли не больше N писем на спам.
WH>Менеджер антивируса следит чтобды проверяли не больше M писем на вирусы итп.
WH>Результат складываем рядом с письмом.


Об этом я и говорю. Решения нет. Если у нас N = M = 1, то на вот он ботлнек на лицо.

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

WH>Теперь можно проверить письмо на спам, вирусы итп
WH>В данном случае висит менеджер проверки на спам и смотрит чтобы одновременно проверяли не больше N писем на спам.
WH>Менеджер антивируса следит чтобды проверяли не больше M писем на вирусы итп.
WH>Результат складываем рядом с письмом.

WH>Короче накладные расходы на кешь процессора ты тут никогда не увидишь.


А откуда такая уверенность? Сколько в "типичном" сервере на 32-процессорной машине занимают издержки на кэш?

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

WH>Даже если делать без надежного хранилища то всеравно рулящие процессы только и будут рулить указателями и плодить процессы которые реально работают.
WH>Просто данные нужно делать не изменяемыми на уровне системы типов и все.


Вот тут не очень понятно. Точнее совсем не понятно. Как можно логически изменяемые данные просто сделать не изменяемыми на уровне системы типов и все?
Покажи на примере. Допустим есть множество лицевых счетов. На сервер поступает поток транзакций вида: изменить баланс л/с, перевести сумму с одного л/с на другой л/с, получить баланс л/с, открыть новый л/с и т.д.
Как тут сделать данные не изменяемыми на уровне системы типов?

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

WH>Еще шедуллер ОС может отслеживать концы SP/SC очередей у процесса и держать его поближе к партнерам.

Зачем тут шедулер ОС?


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

WH>Смотри на каналы в сингулярити.
WH>Они как раз дают такие гарантии.

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

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

R>Об этом я и говорю. Решения нет. Если у нас N = M = 1, то на вот он ботлнек на лицо.
А если нет?
У меня таких ситуаций нет даже на отладочных демонах.
А на продакшене будет скорее что-то типа N = M = 100 это очень сильно зависит от задач и железа.
Так что изивини но мимио.

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

R>А откуда такая уверенность? Сколько в "типичном" сервере на 32-процессорной машине занимают издержки на кэш?
По сравнению с фиксацией транзакции на винте?
Ты серьезно?

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

R>Вот тут не очень понятно. Точнее совсем не понятно. Как можно логически изменяемые данные просто сделать не изменяемыми на уровне системы типов и все?
Данных которые можно очень легко сделать неизменяемыми сильно больше чем кажется.

R>Покажи на примере. Допустим есть множество лицевых счетов. На сервер поступает поток транзакций вида: изменить баланс л/с, перевести сумму с одного л/с на другой л/с, получить баланс л/с, открыть новый л/с и т.д.
R>Как тут сделать данные не изменяемыми на уровне системы типов?
Эти данные будут жить в базе данных по любому.
Те ACID в полный рост с фиксацией на гооооораздо более тормозных винтах.

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

WH>>Еще шедуллер ОС может отслеживать концы SP/SC очередей у процесса и держать его поближе к партнерам.
R>Зачем тут шедулер ОС?
А что как не шедуллер ОС раскидывает потоки по ядрам?

R>Я правильно понял мысль, что в канал потоку может писать произвольное кол-во других потоков. Но если в программе данному конкретному потоку пишет только один другой поток, то сингулярити это гарантированно детектирует и будет использовать более оптимальную реализацию очереди?
Концы каналов могут свободно мигрировать между потоками.
В том числе и внутри других каналов.
Но в один момент времени один конец может находится только в одном потоке.
Также зная состояние конца канала можно точно сказать является ли этот конец в данный момент потребителем или производителем.

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

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

R>>Об этом я и говорю. Решения нет. Если у нас N = M = 1, то на вот он ботлнек на лицо.
WH>А если нет?
WH>У меня таких ситуаций нет даже на отладочных демонах.
WH>А на продакшене будет скорее что-то типа N = M = 100 это очень сильно зависит от задач и железа.
WH>Так что изивини но мимио.


Я не понимаю твой тезис и подход.
Я сказал, что системы исключительно на обмене сообщениями могут быть очень не оптимальными в некоторых ситуациях.
Ты сказал, что не согласен.
Что бы понять насколько технология хороша в общем случае, т.е. для *всех* случаев, надо пытаться её противопоставить не благоприятным для неё условиям, а наиболее НЕблагоприятным.
Никто не спорит, что передача сообщений очень хороша в некоторых случаях. Можно противопоставлять благоприятным условиям, но это даёт практически 0 информации, не считая маркетинговой.

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

Вот я и предлагаю рассмотреть вариант *НЕ* благоприятный для передачи сообщений. Когда структура часто модифицируется, поэтому копировать и реплицировать её не целесообразно. Структура очень большая, сравнимая с размером ОП.
Для кэшей вот например как бывает. Можно взять N = 100, но тогда и кэшировать сможем в 100 раз меньше информации. А если взять N = 1, то тогда кэшировать сможем в 100 раз больше информации.

Либо считаешь, что в принципе вообще нет таких ситуаций, когда нельзя применить полное копирование + атомарная подмена?

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

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

R>>А откуда такая уверенность? Сколько в "типичном" сервере на 32-процессорной машине занимают издержки на кэш?
WH>По сравнению с фиксацией транзакции на винте?
WH>Ты серьезно?


Да, именно по сравнению с фиксацией на винте. И я абсолютно серьезно.

Допустим у нас стоит RAID с максимальной пропускной способностью 320 Мб/с. Т.е. если размер транзакции 4 кб, то мы в пределе можем фиксировать 90'000 т/с. А если размер транзакции 256 байт, то — 1.5 млн т/с.
Т.е. на 32-процессорной машине у нас есть всего 21 мкс на транзакцию. А на 4-процессорной — 2.5 мкс на транзакцию.