Все ли управляемые событиями фреймворки должны быть однопоточными?

Question

http://weblogs.java.net/blog/kgh/archive/2004/10/multithreaded_t.html утверждает, что многопоточные структуры GUI - несостоявшаяся мечта. А как насчет фреймворков без GUI? Распространяется ли это правило на все управляемые событиями фреймворки?

Вот цитата из статьи, которая привлекла мое внимание:

Проблема обработки входных событий заключается в том, что она имеет тенденцию работать в направлении, противоположном большинству операций с графическим интерфейсом. В общем случае, операции с графическим интерфейсом начинаются на вершине стека абстракций библиотеки и идут «вниз». Я работаю над абстрактной идеей в моем приложении, которая выражается некоторыми объектами GUI, поэтому я начинаю в своем приложении и вызываю абстракции GUI высокого уровня, которые обращаются к абстракциям GUI более низкого уровня, которые вызывают уродливые кишки инструментарий, а оттуда в ОС. Напротив, входные события начинаются на уровне ОС и постепенно распределяются «вверх» по уровням абстракции, пока не поступят в код моего приложения.

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

Answer 1

Нет. Даже по практическому правилу просто говорится: «Трудно заставить их работать». Но управляемые событиями фреймворки очень похожи на управляемое событиями моделирование и другие вещи; тот факт, что в Javaworld это сложно, не факт многопоточности, а абстракции, доступные в Java.

В другой среде, например, в Erlang, она достаточно естественная, довольно надежная.

Обновление

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

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

Так почему тупик почти неизбежен? Потому что происходит два разных вида деятельности, которые хотят получить замки в противоположных порядках. И это потому, что «мы, естественно, будем делать блокировку отдельно в каждой абстракции».

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

• " естественно мы будем делать блокировку отдельно в абстракциях" и
• "у нас есть события, которые хотят получить блокировки в противоположных порядках."

По моему опыту, «естественно, Х» обычно означает «я действительно не искал другие варианты». И я очень сомневаюсь, что события хотят приобрести замки в противоположных порядках; ты получаешь замок, ты что-то делаешь и отпускаешь.

Суть в том, что он, кажется, представляет факт, что ему трудно придумать схему, которая работает , работает как теорема, чтобы сказать, что никакая схема не может работать .

Без большого количества подробностей о проблеме сложно создать контрпример, но, как я сказал выше, есть много примеров систем, в которых события происходят в разные стороны, асинхронно, из внутренних процессов и графических интерфейсов. , которые могут иметь много одновременных потоков управления и не блокировать. Эрланг пришел на ум, потому что один класс этих проблем, телефония, является тем, для которого был изобретен Эрланг, и на самом деле такие проблемы , почему Эрланг был изобретен.

Answer 2

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

Конечно, возможно создание многопоточной инфраструктуры пользовательского интерфейса, и я сделал это сам. В конце я преобразовал это, чтобы быть однопоточным. Часть причины подпадает под то, что Чарли сказал о «это слишком сложно». Проблема заключалась в том, что с многопоточной структурой пользовательского интерфейса не только me должен был иметь дело с многопоточностью, но и любой, кто использовал пользовательский интерфейс. Ядро было, конечно, поточно-ориентированным, но тогда любой, кто написал элемент управления, должен был сделать также поточно-безопасным. Не забывайте, что при внесении нескольких изменений в пользовательский интерфейс вы должны были уведомить ядро ​​о том, что вы делаете, чтобы вы не получили частичные обновления. Поскольку пользователь обычно довольно медленный, любой выигрыш в производительности был незначительным, и его можно было бы обойти с помощью асинхронного вызова, если это необходимо для конкретных случаев. Единственная нарезка резьбы на самом деле является подходящей моделью здесь.

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

Answer 3

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

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

Answer 4

Это практическое правило вообще не применяется к фреймворкам без графического интерфейса. См. Уэльскую архитектуру SEDA, см. Yield (code.google.com/p/yield) для хорошей гибридной реализации на python / c ++.

Answer 5

Да и нет.

Фреймворки, управляемые событиями, обычно позволяют вам делать вещи, которые обычно требуют нескольких потоков с одним потоком. Вот почему они обычно однопоточные.

Однако ни в одном определении ни одна управляемая событиями среда не может отправлять события нескольким потокам.

Answer 6

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

Именно так традиционно определяются управляемые событиями рамки. Вот хорошее описание того, как процессы Erlang связаны с циклом событий виртуальной машины:

Процессы Erlang тесно интегрированы с управляемым событиями ядром сетевого ввода-вывода Erlang VM. Процессы могут «владеть» сокетами и отправлять и получать сообщения в / из сокетов. Это обеспечивает элегантность программирования, ориентированного на параллелизм, плюс масштабируемость ввода-вывода, управляемого событиями (виртуальная машина Erlang использует epoll / kqueue под прикрытием).

http://yarivsblog.com/articles/2008/05/18/erlang-vs-scala/

обновление: вот несколько интересных заметок, которые очень повлияли на меня в то время. Обратите внимание, в частности, как плохо взаимодействуют блокировки и обратные вызовы.

http://home.pacbell.net/ouster/threads.pdf