Reaction + multicore
Sergey Schetinin
многоядерностью. Сейчас транзакции всё еще работают под глобальным
локом, плюс конечно GIL, но причиной тому Питон и его скорость. Если
суметь обойти ряд препятсвтвий, то окажется что Реакция решает ряд
открытых ныне вопросов связанных с тем как же использовать растущее
количество ядер в компьютерах.
Многоядерные / многопроцессорные машины это частный случай
распределенных систем и для них стоят те же вопросы -- среди них все
те же что и для однопоточных приложений, но добавляются:
1. Как добиться того чтобы потоки / ядра / машины не портили чужие /
общие данные.
2a. Как избежать простоя из-за локов,
2б. Как бы при этом пореже проводить операции с локами вообще (цена
каждой такой операции растет с количеством участников)
2в. Как избежать дедлоков
3. Как бы так сделать чтобы об этом не надо было думать и компилятор
(или среда) использовал имеющуюся архитектуру автоматически.
К каждому из вопросов необходимо также добавить "и чтобы это
масштабировалось для бОльших, более сложных приложений".
Так вот Реакция дает ответы на все эти воспросы.
1. Транзактная целостность это то чем Реакция по большому счету и
занимается. То есть конечно привлекательность её пока в том что
наконец-то можно по-человечески обрабатывать события, но происходит
это благодаря транзакциям и автоматическому упорядочиванию правил.
Отличие от других систем с транзакциями в том что этот масштабируется
-- даже если правил больше, то из того что они имеют определенные
свойства следует что вся система в целом также обладает определенными
свойствами -- вне зависимости от количества правил. Вот эта
масштабируемость решения, я считаю, на самом деле пока самое главное в
Реакции.
2а. Благодаря STM каждая транзакция работает в изоляции, без каких
либо локов вообще.
2б. Синхронизация происходит один раз за транзакцию, это реже чем GIL
(раз в N опкодов), это реже чем альтернатива (каждая операция над
словарем итп). В целом операций с локом очень и очень немного, причем
участники -- только завершающиеся транзакции. Даже в message-passing
архитектурах можно ожидать больше локов -- каждая передача и прием
сообщения это операция над очередью.
2в. Существует всего один лок. Дедлоки невозможны.
3. Это сложнее описывать, но во-первых правила могут исполняться
параллельно, то есть очередь обработки правил могут обслуживать
несколько потоков (тут конечно появляется новый лок, но эту очередь
легко оптимизировать). Также это меняет обработку неправильного
порядка правил -- требуется чуть больше операций прежде чем
неправильный порядок будет замечен, но поиск порядка -- не нормальный
режим работы и в целом зависимость ускорения от количества
задействованых ядер будет близкой к линейному.
Также можно разделить этапы обработки при помощи latches, тогда
обработка изменения происходит за несколько транзакций, например
первая -- ядро приложения, и затем вторая -- отображение в UI.
Соответственно в таком случае второй этап может начаться раньше,
освободив ядро для обработки следующего события (положим работой с
сетью). Причем код записывается точно так же как и раньше, просто он
собирается воедино иначе. Более того, можно представить как это
реализовать таким образом, что программист не обязан даже знать про
такое разделение обработки -- это не накладывает на него никаких новых
требований. Просто сама система (благодяря подсказке UI-библиотеки)
разделеляет работу по определенной границе.
Причем я еще раз подчеркиваю -- решение масштабируется для бОльших
приложений -- добавляя код не обязательно держать в голове абсолютно
всю систему.
--
Best Regards,
Sergey Schetinin
http://s3bk.com/ -- S3 Backup
http://word-to-html.com/ -- Word to HTML Converter