Добавить любой RSS - источник (включая журнал LiveJournal) в свою ленту друзей вы можете на странице синдикации.
Исходная информация - http://forum.sources.ru. Данный дневник сформирован из открытого RSS-источника по адресу http://forum.sources.ru/yandex.php, и дополняется в соответствии с дополнением данного источника. Он может не соответствовать содержимому оригинальной страницы. Трансляция создана автоматически по запросу читателей этой RSS ленты. По всем вопросам о работе данного сервиса обращаться со страницы контактной информации.[Обновить трансляцию]
Кто-то страницу назад доказывал, что с евентами все просто, а cv одни дэдлоки. А вот оно как... И про smp я не зря говорю, что там может произойти с состоянием эвента (особенно с ручным сбросом) в момент SignalObjectAndWait? А ведь большая часть программистов вообще плохо понимает как оно там устроено в ядре на smp-системах.
Доказывал, что они более уязвимы, да. Как и любой код, писаный руками, вместо использования готовых отлаженных решений. И smp с этим никак не связано, а вот связано как раз с плохим представлением программеров, что не в последнюю очередь связано с нежеланием читать маны, потому что читать код гораздо интереснее.
Я не говорил, что они наши. Хотя, вообще-то да, и наши тоже таковы. Я вообще говорил не за процессы, а за то, к каким результатам это ведёт, что и является причиной следования этим принципам везде, где не положить на риски. Если для тебя это не показатель качества процесса, то прости, что побеспокоил.
2. Им нужно следовать в других компаниях (других отраслей и направленности)?
Я не говорил, что им нужно обязательно следовать. Вот что я сказал, так это то, что сознательный отказ от них обозначается как ССЗБ. Видишь ли, если язык, скажем, не даёт тебе доступа к приватным сущностям класса, это не есть плохой язык, это у тебя странные желания.
Ты серьезно думаешь, что я не знаю как работает waitformultipleobjects?
Что не знаешь, как работает – не думаю. Думаю – что не знаешь, как и где его использовать. Это нормально, я на своём веку много раз думал, что отлично (неважно, о чём я; это и к Плюсам отнести можно, и к технологиям программирования, и к парадигмам, и к патернам проектирования, и многому ещё чему) знаю и умею, что освоил и неоднократно применял, но вот внезапно оказывалось, что я глубоко заблуждался, потому что уже вроде бы хорошо знакомое вдруг раскрывало свой потенциал куда масштабнее моих о нём представлений.
Если самолёты управляются софтом на windows, то мне страшно.
Есть по меньше мере одна кампания, у которой изделия летают на софте под эмбеддед ОС, построенной на WinAPI. И эта компания является крупным подрядчиком хорошо вам известной, недавно некисло оскандалившеся, кампании государственного значения. Нет, винды на самолётах нет, она плохо портабельна на те могзи, которые там используются, а WinCE давно не поддерживается, но вот как раз у того подрядчика широко используются индустриальные камни Intel-а. В ходу больше ARM, PPC и кучи микроконтроллеров. Чем больше разных, тем лучше, потому что надёжнее, меньше зависимостей от аппаратных багов. Так-то там обычно если не самописное, то некое производное от POSIX. Это дешевле, т.к. код зачастую открыт, портировать недолго. Но фаза сертификации никуда не девается, и знаково дешевле всё равно не выходит. Так что да, деньги там ...хм, "отмываются" некислые.
Но вот где винды много, я бы даже сказал, где кроме неё ничего и нет, но побоюсь за всё и всех говорить, так это в процессах проектирования, создания, тестирования, верификации и сертификации. Я знаком с процессами трёх забугорных кампаний, две из которых упомянул, везде винда. За наши кампании, думаю, говорить излишне. Как думаешь, это крупный бизнес? Ему не наплевать на риски? Он предпочтёт выбирать решения по принципам надёжности и гарантиям или по сферическим проприетарность vs открытость?
scrambrella: В Microsoft давно поняли, что на WINAPI программировать невозможно и создали C#.
Линь в плане графических прог вообще жопа. X, KDE, Gnome, чего там ещё, и под каждого свой API. Под линь QT вообще без вариантов. Ну или Жаба, если религия позволяет.
Profi: Я боюсь, что нормального решения нет. Только самому мониторить или атрибуты файла или его доступность. Однако, он может быть открыт без блокировки чтения. А тот же Watcher не реагирует на открытие, только на создание, изменение, удаление.
WinAPI является одним из лучших ОС API в мире. Объём его документации превышает таковой для любых других API вместе взятых, количество аспектов, охватываемых WinAPI, от безопасности и криптографии до робастности 24/7 приложений, сравним с суммой аспектов остальных API вместе взятых, и то при условии навешивания поверх них ассетов сторонней разработки.
В первый раз вижу, чтобы жирность расценивалась как преимущество. Есть, конечно, борцы сумо, но это скорее исключение, чем правило.
Но лично я забил рефакторить, ибо интерфейс моих классов 2001 года издания, обеспечивающие не меньшую портабельность между WinAPI и POSIX, гораздо удобнее pthreadнутого std.
Если это какие-то личные поделки для себя, то вопросов нет. А так похоже на nih- синдром :)
D_KEY: Если самолёты управляются софтом на windows, то мне страшно.
По поводу крупного бизнеса нужны пруфы. Насколько мне известно, там мало windows.
По поводу сравнения с POSIX. Не очень понятно, зачем сравнивать конкретную ОС со стандартом, под который попадает очень широкий спектр ОС. А если рассмотрим частичную совместимость, так вообще большая часть существующих ОС.
Можно взять конкретный linux, например, и сравнивать, будет более корректно.
А саму винду-то на высоких нагрузках кто-то использует? Насколько мне известно, по крайней мере на серверах, её довольно мало.
Добавлено
Вообще есть мнение, что MS скоро может переехать на linux ядро и тогда холивары потеряют актуальность :D
Придется им повозиться с совместимостью, но по-моему тенденции последних изменений намекают на возможность такого перехода.
Вот только почему-то такая штука как docker в лине есть нативно с его стрёмной системой прав, в винде же он надстройка над hyper-v. Без виртуализации, видимо, никак не сделать в столь гибкой системе.
Ну справедливости ради, docker и основан на API линукса :)
Кстати, на POSIX голом никакой docker ты не сделаешь.
Ещё мне кажется, что в новых версиях винды таки смогли поддержать docker без виртуализации. WSL же, нет?
Ты статью читал? Судя по всему, только заголовок. Ок, мой изначальный вопрос в силе: хочу увидеть реализацию блокирующей очереди (несколько писателей - читателей) на событии с автосбросом. Ты же сам сказал, что это проще, чем с cv. Я могу сразу прогнать тесты.
Скрытый текст
все простые реализации на event'ах, которые я тестировал, с треском проигрывают решениям на cv по производительности
Джуну надо целый курс лекций читать, а профи и так знает.
Ммм. Кто-то страницу назад доказывал, что с евентами все просто, а cv одни дэдлоки. А вот оно как... И про smp я не зря говорю, что там может произойти с состоянием эвента (особенно с ручным сбросом) в момент SignalObjectAndWait? А ведь большая часть программистов вообще плохо понимает как оно там устроено в ядре на smp-системах.
Если не троллишь, а просто этого не понял, нахрена я тут тогда тут распинаюсь?
А с чего ты взял, что:
1. ваши производственные процессы идеальны?
2. Им нужно следовать в других компаниях (других отраслей и направленности)?
И вообще это оффтоп.
Зачем тогда IO приплетал? Всё-таки троллишь? Ну ок, тогда до свиданья. Поехали!
Ты серьезно думаешь, что я не знаю как работает waitformultipleobjects? По моему троллишь как раз ты. Давно мог дать ссылку на простую (проще чем на cv) и эффективную реализацию очереди на евентах... Тогда бы вопрос был исчерпан.
Вот поэтому винда правит крупным бизнесом и домашними ПК, где важны стоимости корпоративных решений и простота администрирования, а POSIX – малым и средним бизнесом, где важны стоимости владений решениями и относительно велики бизнес-риски.
Пруф чего? Того, как доC++11легаси, разработанный под WinAPI, переделать под std? А что ещё ты там вычитал? Ах да, ты ж написал, что.
Ну, молодец он, что могу сказать. Хорошая статья для чьего-нибудь FAQ-а. Но лично я забил рефакторить, ибо интерфейс моих классов 2001 года издания, обеспечивающие не меньшую портабельность между WinAPI и POSIX, гораздо удобнее pthreadнутого std. К тому же нет путаницы с названиями классов и интуитивным их пониманием, к которой в std нужно привыкнуть. А уж CV просто жуть. Я-то надеялся, что их поправят под что-то более удобоваримое, как-никак 21-ый век 10 лет уж как шагает по миру. Но нет, как были неудобным фуфлом в pthread, так им и остались.
Очевидно, что в SMP системах профит от нее намного меньше.
И снова просто note, эта фраза явным образом следует из... Я как будто и не писал выше о Рихтере, да? Его советы по недопущению дидлуков никем не читаны, да? Ну да фиг с ним, с Рихтером, как вы вообще тогда CV пишете, без знания теории? ...пожалуй, я не буду комментировать мат.часть. Ну вот как нет желания объяснять, почему, например, к std::string_view нельзя относиться так же, как к std::string. Джуну надо целый курс лекций читать, а профи и так знает.
Ты пытаешься натянуть сову на глобус. Юридические аспекты в этом вопросе лично меня мало волнуют
Опять троллишь? Причём тут юриспруденция? Речь о корректно поставленном бизнес-процессе. Который корректно поставлен, благодаря полноте и качеству документации. Если не троллишь, а просто этого не понял, нахрена я тут тогда тут распинаюсь?
В другом крайнем случае, когда на одного писателя будет 100500 читателей, без приоритетности он чёрта с два дождётся обнуления их активного количества.
Если программист идиот, то он может и сделать 100500 потоков-читателей, а также сделать множество других глупостей. На практике крайне редко имеет смысл их создавать больше, чем количество логических процессоров.
Пф. Событие с автосбросом. Единственное изменение во всей процедуре – один флажок в одном из API-вызовов.
Да вот нифига. Сами мелкомягкие не дают адекватного решения на событиях с автосбросом. И призывают использовать iocp, или, внезапно, cv Пруф, разумеется, будет.
Смак SignalObjectAndWait() в том, что она гарантирует перевод вызвавшей её нитки в ожидающее состояние перед тем, как она отсигналит сигнализирующим объектом. Ты просто не сможешь простым путём это сделать никак иначе.
Это понятно, но...
Цитата
Use extreme caution when using SignalObjectAndWait and PulseEvent with Windows 7, since using these APIs among multiple threads can cause an application to deadlock. Threads that are signaled by SignalObjectAndWait call PulseEvent to signal the waiting object of the SignalObjectAndWait call. In some circumstances, the caller of SignalObjectAndWait can't receive signal state of the waiting object in time, causing a deadlock.
Очевидно, что в SMP системах профит от нее намного меньше. И в отличие от фьютексов функция непригодна для user-mode примитивов синхронизации.
Вот поэтому винда правит крупным бизнесом и домашними ПК, где важны стоимости корпоративных решений и простота администрирования, а POSIX – малым и средним бизнесом, где важны стоимости владений решениями и относительно велики бизнес-риски.
Прикинь, когда — не дай бог – падает самолёт, комиссии смотрят код в последнюю очередь и в очень малом проценте инцидентов. Почему? Потому что это не требуется. Вся инфа берётся из документации и логов. А этого в свою очередь достаточно, потому что там исчерпывающая документация. Если бы это было не так, в комиссиях должны были бы состоять исключительно программисты, но среди них крайне мало конструкторов, схемотехников, специалистов по физике атмосферы, прочнистов итд итп и др.
Ты пытаешься натянуть сову на глобус. Юридические аспекты в этом вопросе лично меня мало волнуют. Для отдельных отраслей есть специальные дистрибутивы linux'а, где много чего гарантируется и документировано. По факту там просто деньги отмыли на этом, но это разговор для другой темы.
В общем, забудьте и больше никогда не вспоминайте о тезисе, что открытый код якобы надёжней, потому что в него всегда можно заглянуть. Это миф.
Я нигде не писал о надежности, я писал о кривости архитектуры, что не одно и тоже. На кривой архитектуре можно вполне построить работоспособное приложение.
scrambrella: Ключевой в математике является концепция актуальной бесконечности. Там где появляется актуальная бесконечность элементарная математика переходит в высшую, формальная логика - в диалектическую.
Что есть "с приоритетом у писателей"? Эта фраза мне мало о чем говорит. И в чем практический смысл такого приоритета?
В том, что перед записью нужно захватить ресурс монопольно, и следовательно читатели должны его держать, когда они есть, и отпускать, когда ни один из них не держит ресурс, но и не блокировать друг друга, ибо в этом нет надобности, они его не меняют. В другом крайнем случае, когда на одного писателя будет 100500 читателей, без приоритетности он чёрта с два дождётся обнуления их активного количества. Серьёзно? Мне пришлось это написать?
С одним писателем достаточно двух объектов синхронизации и по одному API-вызову на входе/выходе в/из КС со стороны читателей и по два для писателя. В ситуации с несколькими писателями дело усложняется.
Собственно, эффективную (без пробуждения всех читателей при записи) и простую (сопоставимую по сложности с CV) реализацию писателей-читателей (можно без приоритетов) на евентах я бы тоже хотел увидеть.
Пф. Событие с автосбросом. Единственное изменение во всей процедуре – один флажок в одном из API-вызовов.
А какие с CV дедлоки? Там есть ложные пробуждения, но это не так страшно, как обратная ситуация с Event'ами.
Такие, что ты сам их пишешь и сам же управляешь потоками событий по ним. Если ты способен писать безошибочно с первого раза, то ты уникум, тебе надо памятник при жизни ставить.
Она нифига не атомарная на SMP системах, о чем у них и написано в документации.
Она выполняется ровно так, как описано. Пробуждение другой нити перед вызвавшей SignalObjectAndWait() суть нормальное явление, ибо для объектов синхронизации все ожидающие нитки равноправны. Такова их архитектура. Ничего не поменялось бы, если б сигнализирующий объект переводился бы в сигнальное состояние после того, как вызывающая SignalObjectAndWait() нитка реально вошла б режим ожидания. Всё равно при наличии нескольких ожидающий проснуться может любая, и решает это планировшик потоков. То, что написано в документации как предупреждение, суть просто напоминание, фактически ему там делать нечего, просто Note для забывчивых. Я ж говорю, мат.часть надо знать.
Смак SignalObjectAndWait() в том, что она гарантирует перевод вызвавшей её нитки в ожидающее состояние перед тем, как она отсигналит сигнализирующим объектом. Ты просто не сможешь простым путём это сделать никак иначе.
Скольким разработчикам этот функционал нужен? 0.1% наберется?
Всем, кто пишет сервисы. Таковых много? Я не знаю. Но без этого функционала они связаны по рукам и ногам.
Просто посмотри, например, на такую ситуацию: ты пишешь код обновления своего ПО, которое может эксплуатироваться одновременно под разными учётками в терминальных сессиях или даже просто под fast user switch, и тебе нужно сделать это правильно, т.е. выгрузив все свои экземпляры и после обновления загрузить снова, не потеряв при этом данных пользователей, которые вот прям счас с твоим ПО активно работают, а главное – не быть уязвимым к злонамеренным атакам, посредством фэйковых служебных пакетов саботирующих работу твоего ПО. Конечно, это вполне себе решается и в POSIX, но насколько это проще, безопаснее и быстрее решается в WinAPI, лично я могу сравнивать. Там тебе всё готовое уже. Даже журналирование стандартизировано, что легко автоматизирует множество административных задач, на которых уже построена значительная часть корпоративной инфраструктуры твоей компании, и встроить туда ещё один объект аудита занимает пару минут. На рубеже прошлых десятилетий мне пришлось плотно окунуться в сферу сервисов и security API. Если заглянешь в раздел WinAPI у нас, то я отметился, пожалуй, в каждой теме по сервисам. Правда, о security вопросов там, вроде бы, не было.
У POSIX можно открыть исходники и понять как оно реализовано, что ни скажешь о API MS.
Этот аргумент не просто ни разу не аргумент, а никогда им и не был. Прикинь, когда — не дай бог – падает самолёт, комиссии смотрят код в последнюю очередь и в очень малом проценте инцидентов. Почему? Потому что это не требуется. Вся инфа берётся из документации и логов. А этого в свою очередь достаточно, потому что там исчерпывающая документация. Если бы это было не так, в комиссиях должны были бы состоять исключительно программисты, но среди них крайне мало конструкторов, схемотехников, специалистов по физике атмосферы, прочнистов итд итп и др.
Для сравнения могу предложить такую задачку. В Холиварах никто не захотел задуматься, предлагаю задуматься тут. Чтоб не отправлять по ссылке, сцитачу сюда:
В документации сказано: «функция void sort(int *vec, size_t size) должна выполнять сортировку массива vec, размером size. Сортировка осуществляется по возрастанию, результат замещает исходный vec.» Требуется разработать набор тестовых сценариев для проверки этого требования. Естественно так, чтобы их можно было рассматривать как доказательную базу корректности реализации sort() согласно описанию её поведения.
Поначалу может показаться, что это некая ересь, как можно что-то тестировать глубже, чем интуитивно потыкать по кнопкам, не зная, как оно устроено, а тут аж доказательную базу хотят. Но немного подумав, внезапно окажется, что алгоритм и сырцы для этого без надобности от слова совсем. Мы знаем, как должна вести себя эта функция. Мы можем однозначно определить, каким должен быть её результат по абсолютно любому набору входов. Что ещё надо-то? Качество документации — вот главный пасс-критерий качества кода, и его реально достаточно.
Это, конечно, простой пример, потому что мы все прекрасно знаем, что такое сортировка, но а чем качественно-то отличается любая другая функция от этой? Риторический вопрос. В общем, забудьте и больше никогда не вспоминайте о тезисе, что открытый код якобы надёжней, потому что в него всегда можно заглянуть. Это миф.
Да причем тут гибкость? Адекватно вообще пихать столько аргументов в одну функцию?
Напиши прокси для своих более узкоспециализированных нужд. Собственно любой фрейморк именно это тебе и делает, и выбирая фреймворк, ты не более чем выбираешь комплект сужений имеющейся изначально гибкости. Это же возможно? А как иначе, при таком-то количестве наблюдаемых фреймворков. Это было бы возможно без изначально спроектированной и реализованной гибкости? Отнюдь не факт, всё зависит от потребностей. Вот нет в POSIX гибкой системы секьюрити и межпроцессного взаимодействия, приходится юзать богомерзкие сокеты, проектировать, программировать и отлаживать свои протоколы, строить вокруг него стену из файрвола и правил фильтрации портов и адресов. Ну ок, это ваш выбор. Точнее, вашей ОСи. Ещё точнее – вашего API. Так что наблюдаемое разнообразие фреймворков над WinAPI говорит лишь за то, что я прав. И именно благодаря гибкости WinAPI у вас богатый выбор проксей над ним.
ЗЫ: я раньше тоже был сторонником WinApi. Пока серьезно не занялся осдевом (как хобби) и не понял внутренне устройство ОС. После этого мои взгляды резко изменились.
Вот поэтому винда правит крупным бизнесом и домашними ПК, где важны стоимости корпоративных решений и простота администрирования, а POSIX – малым и средним бизнесом, где важны стоимости владений решениями и относительно велики бизнес-риски.
И кстати, если модель синхронизации винды так прекрасна, то почему те же евенты не добавили в c++? Только не надо говорить, что "потому что их нет в ядре nix": там они тривиально реализуются на фьютексах. А причина, насколько я знаю, в том, что в комитете справедливо решили, что Event'ы очень часто порождают весьма не очевидные баги в синхронизации
Нет, в Комитете решили, что на этот момент существует уже слишком много доСтандартных решений, и так будет гораздо проще рефакторить много легаси. А почему их много, думаю, объяснять не надо: проще было с...лямзить готовый и открытый pthread, чем писать и отлаживать свои самокаты.
В цикле пробежаться, реализовав предикат на if-ах. А как на STL и чем это круто?
Пробежаться в цикле тебе и без QVector::fill() было бы несложно, согласись, но коли речь зашла за сервисные функции и методы, то речь идёт об обобщённой задаче, ибо на каждую хотелку методов не напасёшься. Например
зануляет все, которые при делении на 7 дают в остатке 4. При этом db может быть чем угодно, лишь бы поддерживало модель контейнер+итераторы, и предикат пиши сам, какой нужен. А ещё первым параметром можно указать политику параллельного исполнения, типа там std::execution::parallel_policy, и если в твоей библиотеке оно реализовано, то ок. Ну, не реализовано, ну и ладно, а у кого-то реализовано, и этот код получит профит. Наверно, получит профит... слишком простая задача. Но ведь и гораздо сложнее бывают.
С другой стороны, если говорить WaitForMutlipleObject, то вещь это специфическая и для приложений с большой нагрузкой ввода-вывода малополезная (прежде всего сервера): там используются те же очереди на IOCP/epoll. Почему? Все просто: эта функция ограничена 64 объектами ожидания на поток (причем преодолеть это ограничение технически MS не может и на то есть объективные причины), что ставит крест на масштабируемости. Поэтому область ее применения все же не высоконагруженные приложения, где не так много объектов за которыми нужно следить, а в этом случае сложно увидеть разницу в производительности по сравнению с той же реализация на CV (ну проснутся потоки лишний раз и опять уснут, катастрофы нет).
Так её и не используют на высоких нагрузках. Так-то для этого уже мульён лет другие объекты синхронизации предназначены. А вот для чего пользуют (просто пример! пользовать в своих проектах не более чем как демонстрацию концепции):
Вот только почему-то такая штука как docker в лине есть нативно с его стрёмной системой прав, в винде же он надстройка над hyper-v. Без виртуализации, видимо, никак не сделать в столь гибкой системе.
Недавно в некотором проекте мне захотелось, чтобы вывод был не только в консоль,
а куда я захочу (или никуда) Тогда я написал класс MyCout. И реализовал
только те возможности, которые мне были необходимы. Только теперь этот класс
писал не в консоль, а в интерфейс.
А зачем было себя ограничивать в интерфейсе, если можно просто написать потомка std::basic_streambuf<> и перекрыть несколько виртуальных методов? И пиши себе стандартными классами хоть в сокеты, хоть в COM:, куда там ты напрограмишь в методах.
Пруф, разумеется, будет.
