Разговор пошел по кругу. если вам повезло никогда не ловить

Question

Разговор пошел по кругу. если вам повезло никогда не ловить

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

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

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

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

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

++++++++++++++

и давайте таки вынесем эту дискуссию из DS-чата. Если кто желает ее продолжить в стороннем канале, поделитесь ссылкой.

#database #programming #russian #software

0

14.08.2019

1 ответов

22 просмотра

Denis Borovikov · Accepted Answer

Плюс в том, что код выглядит абсолютно линейно как буд-то это обычный синхронный код. Дополнительный плюс еще по сравнению с питоном в том, что все не нужны никакие специальные библиотеки. Весь код работает с IO асинхронно в любом случае и из коробоки. P.S. По поводу организации доступа к памяти - можно добиться ровно того же эффекта, что и с io loop завернув код в актор, который серелизует обращение к его внутреннему стейту. Все, нет проблемы.

215 похожих чатов

Разговор пошел по кругу. если вам повезло никогда не ловить

1 ответов

Похожие вопросы