Проклятая тема
Apr. 16th, 2013 10:17 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassКак известно, в программировании есть несколько проклятых тем. Т.е. задач, которые сами по себе просты, но их общего (повторно-используемого, кросс-платформенного, не заставляющего глаза течь кровью) решения не бывает и приходится каждый раз мутить какие-то велосипеды.
Одна из таких тем: прерывание длительных и блокирующих операций. Смежная - показ прогресса для таких операций. Вот, например, в контексте скалы: http://ru-scala.livejournal.com/36634.html
Почему эта тема проклята?
Во-первых, прерывание означает либо два потока, либо callback изнутри операции, вызывающий проверку наличия ввода от пользователя (Application.DoEvents/Application.ProcessMessages). Средний разработчик от многопоточности и callback бежит как от огня.
Во-вторых, i/o операции изначально сами по себе блокирующие. Всякие там чтения из сокетов, файлов(на сгнившей файловой системе примонтированной с выключенного сервера), rs232-портов с забытыми таймаутами и прочего зла. Реализация асинхронного i/o - жесточайшее уныние, что с overlapped, что с completion ports, что с select и прочими epoll.
В уютной сишечьке или недалеко от них ушедших C++ и Delphi - это по крайней мере, помещается в мозг, в дотнетах же, жабах, рантаймах хаскеля и прочих порождениях геенны огненной - либо авторы рантайма озаботились прерыванием операций, либо изобретение велосипеда вырождается в чад угара и лавирования между GC и разными уровнями представления данных.
Во-третьих, "у меня на столе все работает". Когда сервера не выключаются, сеть работает, диски без бэдов и железо отвечает вовремя - операции отрабатывают быстро, или можно их выполнять мелкими блоками и проверять какие-нибудь флаги отмены.
В-четверых, часто эти операции завернуты в десятки слоев чужих библиотек, например, "выполнение запроса к БД и выборка неизвестного количества миллионов записей, потому что база не знает сколько записей подпадает под условие". Если повезет - метод "прервать и свалится с исключением в потоке выполнения запроса" будет в API и даже после его применения внутренние структуры данных не превратятся в кашу. Если нет - то только убивать себя о стену.
Одна из таких тем: прерывание длительных и блокирующих операций. Смежная - показ прогресса для таких операций. Вот, например, в контексте скалы: http://ru-scala.livejournal.com/36634.html
Почему эта тема проклята?
Во-первых, прерывание означает либо два потока, либо callback изнутри операции, вызывающий проверку наличия ввода от пользователя (Application.DoEvents/Application.ProcessMessages). Средний разработчик от многопоточности и callback бежит как от огня.
Во-вторых, i/o операции изначально сами по себе блокирующие. Всякие там чтения из сокетов, файлов(на сгнившей файловой системе примонтированной с выключенного сервера), rs232-портов с забытыми таймаутами и прочего зла. Реализация асинхронного i/o - жесточайшее уныние, что с overlapped, что с completion ports, что с select и прочими epoll.
В уютной сишечьке или недалеко от них ушедших C++ и Delphi - это по крайней мере, помещается в мозг, в дотнетах же, жабах, рантаймах хаскеля и прочих порождениях геенны огненной - либо авторы рантайма озаботились прерыванием операций, либо изобретение велосипеда вырождается в чад угара и лавирования между GC и разными уровнями представления данных.
Во-третьих, "у меня на столе все работает". Когда сервера не выключаются, сеть работает, диски без бэдов и железо отвечает вовремя - операции отрабатывают быстро, или можно их выполнять мелкими блоками и проверять какие-нибудь флаги отмены.
В-четверых, часто эти операции завернуты в десятки слоев чужих библиотек, например, "выполнение запроса к БД и выборка неизвестного количества миллионов записей, потому что база не знает сколько записей подпадает под условие". Если повезет - метод "прервать и свалится с исключением в потоке выполнения запроса" будет в API и даже после его применения внутренние структуры данных не превратятся в кашу. Если нет - то только убивать себя о стену.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2013-04-16 07:28 pm (UTC)как и асинхронный ввод-вывод, кстати.
no subject
Date: 2013-04-16 08:41 pm (UTC)no subject
Date: 2013-04-16 10:18 pm (UTC)ну и как бы "автор -- мудак" не считается, от этого защты нет.
а на все остальное в драйвере была точка ABORT для отмены операции.
ну и да, у контроллера должен был быть соответсвующий битик в CSR, ну так у всех стандартных устройств и было (нет, MX -- не стандартное, это вообще недоразумение)
no subject
Date: 2013-04-17 08:04 am (UTC)no subject
Date: 2013-04-17 08:09 am (UTC)обещало -- это обычно 000200 в CSR. как после этого можно не отдать что-то в дата?
более того, хорошим тоном не в цикле крутиться, а 000100 в CSR поставить и отдаться до прерывания.
а контроллер винта по DMA работать должен.
как и дисковода (если он не MX, разумеется. но MX жить не должен).
он, собственно и работал, кажется, потому как загрузка из пульта с него была возможна без написания программ, просто программированием регистров.
no subject
Date: 2013-04-17 08:42 am (UTC)Ну, да, говорю же, все в некритическую часть. Но если оно может появиться через (условно) секунду, а может и через 100 мксек уже протухнуть (придет следующий), то механизм с прерываниями может и не успеть, особенно если еще кто-нибудь в такую же критическую часть уедет и не вернется. Пока это какой-нибудь tty на 9600 - да плевать, успеет сто раз. А если тот же тты но на 115200?
Не помню уже в чем там была проблема, но как-то не получалось. Контроллер не тот что от СМ, а тот что от ДВК, он там вуууууумный был как вутка.
no subject
Date: 2013-04-17 08:49 am (UTC)с железкой разбираться.
да я понял, что для MFM винтов, а не для будущих антен.
no subject
Date: 2013-04-16 07:53 pm (UTC)Что же касается асинхронщины, то она вся на таких заплатках к говнопосиксу и винапи, что её не обернуть в разумную форму без потерь. А других ядер у нас нет.
no subject
Date: 2013-04-17 03:45 am (UTC)В винапи асинхронный IO как раз первичен, а синхронный сделан поверх оного, насколько я знаю. Другой вопрос, что использовать все привыкли синхронный, ибо проще.
no subject
Date: 2013-04-17 09:39 am (UTC)no subject
Date: 2013-04-16 08:02 pm (UTC)no subject
Date: 2013-04-16 08:29 pm (UTC)Средний разработчик об этом не знает. А если знает, то не правильно. Как-то в группе, делавшей реалтайм "на системе, которая всё берёт на себя", нашёлся только один человек, который, нет не проверил, а просто понял, что там с прерываниями и семафорами написано.
no subject
Date: 2013-04-16 11:11 pm (UTC)no subject
Date: 2013-04-17 03:46 am (UTC)no subject
Date: 2013-04-17 04:59 am (UTC)Правда, слышал, на полевых испытаниях реальность сказала "Привет!". А что они делали потом, фиг знает. Может тул какой купили хитрый, может кого-то с мозгами наняли. Но последнее врядли.
no subject
Date: 2013-04-16 08:37 pm (UTC)Примеры (от балды про винду):
низкий уровень - WaitForMultipleObjects и ваши волосы станут белыми. Может быть даже и пушистыми, но это уже как повезет - не все драйверы порождают все нужные события.
средний уровень - например, на винде в данный момент глупо писать свой TCP-сервер, потому как есть ряд системных сервисов, через которые все необходимое можно получить в готовом, высокопроизводительном виде.
высокий уровень - следование идеологии разработки таких вещей в выбранной среде и понимание её ограничений. Т.к. рантайм всегда ограничен.
no subject
Date: 2013-04-16 08:46 pm (UTC)Я только про http.sys в курсе, но он для веб-серверов вроде же.
no subject
Date: 2013-04-16 11:35 pm (UTC)no subject
Date: 2013-04-17 04:51 am (UTC)А если речь идет о своем протоколе, совместимом с http, то тут-то у нас появляется большой выбор готовых сервисов, начиная с http.sys и далее по всяким wcf/wws/etc. Ведь http по большому счету - это всего лишь текстовый заголовок перед данными.
no subject
Date: 2013-04-17 04:58 am (UTC)Ну а для закрытых бинарных протоколов есть вагон готовых оберток и примеров по работе с IO Completion Ports.
no subject
Date: 2013-04-17 06:36 am (UTC)С тисипи же бинарный поток приходит, что вам еще надо?
no subject
Date: 2013-04-17 06:46 am (UTC)Впрочем, судя по всему, имелось в виду наличие API для асинхронного обмена и его оберток.
no subject
Date: 2013-04-17 06:53 am (UTC)Логика сервера достаточна проста, зачем там обертки?
no subject
Date: 2013-04-16 11:34 pm (UTC)no subject
Date: 2013-04-17 03:27 am (UTC)А уж как убивать по таймауту... лично я предпочитаю свои потоки. Приличного API темплейта для асинхронных вызовов не видел еще. Ну да я много чего в жизни не видел. Судя по вашей записи, вы тоже еще не видели.
no subject
Date: 2013-04-17 05:08 am (UTC)no subject
Date: 2013-04-17 05:16 am (UTC)no subject
Date: 2013-04-17 06:20 am (UTC)они просто разделятся и будут писать свои форки
уже так и случилось миллион раз
no subject
Date: 2013-04-17 06:22 am (UTC)no subject
Date: 2013-04-17 05:30 am (UTC)no subject
Date: 2013-04-17 06:54 am (UTC)Это подрывает позиции производителей фрэймворков! %))
no subject
Date: 2013-04-17 06:15 am (UTC)В юниксе да.
В винде-нт изначально нет, сразу асинхронно, а для win32 сделали блокирующие прокладки.
> Реализация асинхронного i/o - жесточайшее уныние
Вкусовщина. Если у вас мозги заточены на read(buf) и больше не гнутся.
> callback изнутри операции, вызывающий проверку наличия ввода от пользователя (Application.DoEvents/Application.ProcessMessages).
Изучите, что такое флаги и как они могут выставляться.
Впрочем не надо, не будете конкурентом.
no subject
Date: 2013-04-17 06:33 am (UTC)О каких флагах идет речь?
no subject
Date: 2013-04-17 06:39 am (UTC)no subject
Date: 2013-04-22 11:15 am (UTC)"callback изнутри операции, вызывающий проверку наличия ввода" -- неправильная организация потоков
message consumer thread должен запустить поток операции и передать ему объект-семафор "is_interrupted"
потом при "наличии ввода" message consumer thread должен выставить семафор
на который поток с операцией должен поглядывать и прерываться, если ему удобно
семафор ваще-то вполне определённая штука, поэтому обычно юзают не системный semaphore, а обычный булев флаг-переменная, тока у него должен быть модификатор volatile
архитектурно, НЕЛЬЗЯ вводить ОС-специфическую логику в операцию
как вы этого не заметили -- не понимаю; если заметили и не делаете, то ваще не понимаю
no subject
Date: 2013-04-22 11:20 am (UTC)Булев флаг с volatile допустимо, конечно, но у меня расчетные потоки обычно спят, ожидая либо таймаута, либо одного из пары событий - выход или сообщение про необходимость выполнить некую операцию.
no subject
Date: 2013-04-22 12:05 pm (UTC)за "изобретение" собственных средств "синхронизации" нужно гнать ссаными тряпками.
> а обычный булев флаг-переменная, тока у него должен быть модификатор volatile
volatile, внезапно, не защищает от переупорядочивания обращений к памяти процессором.
no subject
Date: 2013-04-18 07:11 am (UTC)no subject
Date: 2013-04-22 11:19 am (UTC)таки да! проблема и костыли известны
потом речь идёт идёт о своём коде, где "callback изнутри операции, вызывающий проверку наличия ввода от пользователя"
что очевидно не случай библиотек