Qraizer: В том, что перед записью нужно захватить ресурс монопольно, и следовательно читатели должны его держать, когда они есть, и отпускать, когда ни один из них не держит ресурс, но и не блокировать друг друга, ибо в этом нет надобности, они его не меняют. В другом крайнем случае, когда на одного писателя будет 100500 читателей, без приоритетности он чёрта с два дождётся обнуления их активного количества. Серьёзно? Мне пришлось это написать?
С одним писателем достаточно двух объектов синхронизации и по одному API-вызову на входе/выходе в/из КС со стороны читателей и по два для писателя. В ситуации с несколькими писателями дело усложняется.Пф. Событие с автосбросом. Единственное изменение во всей процедуре – один флажок в одном из API-вызовов.
Такие, что ты сам их пишешь и сам же управляешь потоками событий по ним. Если ты способен писать безошибочно с первого раза, то ты уникум, тебе надо памятник при жизни ставить.И это абсолютно неважно, когда речь идёт о скорости и стоимости выхода в стадию продакнша.
Она выполняется ровно так, как описано. Пробуждение другой нити перед вызвавшей SignalObjectAndWait() суть нормальное явление, ибо для объектов синхронизации все ожидающие нитки равноправны. Такова их архитектура. Ничего не поменялось бы, если б сигнализирующий объект переводился бы в сигнальное состояние после того, как вызывающая SignalObjectAndWait() нитка реально вошла б режим ожидания. Всё равно при наличии нескольких ожидающий проснуться может любая, и решает это планировшик потоков. То, что написано в документации как предупреждение, суть просто напоминание, фактически ему там делать нечего, просто Note для забывчивых. Я ж говорю, мат.часть надо знать.
Смак SignalObjectAndWait() в том, что она гарантирует перевод вызвавшей её нитки в ожидающее состояние перед тем, как она отсигналит сигнализирующим объектом. Ты просто не сможешь простым путём это сделать никак иначе.Всем, кто пишет сервисы. Таковых много? Я не знаю. Но без этого функционала они связаны по рукам и ногам.
Просто посмотри, например, на такую ситуацию: ты пишешь код обновления своего ПО, которое может эксплуатироваться одновременно под разными учётками в терминальных сессиях или даже просто под fast user switch, и тебе нужно сделать это правильно, т.е. выгрузив все свои экземпляры и после обновления загрузить снова, не потеряв при этом данных пользователей, которые вот прям счас с твоим ПО активно работают, а главное – не быть уязвимым к злонамеренным атакам, посредством фэйковых служебных пакетов саботирующих работу твоего ПО. Конечно, это вполне себе решается и в POSIX, но насколько это проще, безопаснее и быстрее решается в WinAPI, лично я могу сравнивать. Там тебе всё готовое уже. Даже журналирование стандартизировано, что легко автоматизирует множество административных задач, на которых уже построена значительная часть корпоративной инфраструктуры твоей компании, и встроить туда ещё один объект аудита занимает пару минут. На рубеже прошлых десятилетий мне пришлось плотно окунуться в сферу сервисов и security API. Если заглянешь в раздел WinAPI у нас, то я отметился, пожалуй, в каждой теме по сервисам. Правда, о security вопросов там, вроде бы, не было.
Этот аргумент не просто ни разу не аргумент, а никогда им и не был. Прикинь, когда — не дай бог – падает самолёт, комиссии смотрят код в последнюю очередь и в очень малом проценте инцидентов. Почему? Потому что это не требуется. Вся инфа берётся из документации и логов. А этого в свою очередь достаточно, потому что там исчерпывающая документация. Если бы это было не так, в комиссиях должны были бы состоять исключительно программисты, но среди них крайне мало конструкторов, схемотехников, специалистов по физике атмосферы, прочнистов итд итп и др.
Для сравнения могу предложить такую задачку. В Холиварах никто не захотел задуматься, предлагаю задуматься тут. Чтоб не отправлять по ссылке, сцитачу сюда:Поначалу может показаться, что это некая ересь, как можно что-то тестировать глубже, чем интуитивно потыкать по кнопкам, не зная, как оно устроено, а тут аж доказательную базу хотят. Но немного подумав, внезапно окажется, что алгоритм и сырцы для этого без надобности от слова совсем. Мы знаем, как должна вести себя эта функция. Мы можем однозначно определить, каким должен быть её результат по абсолютно любому набору входов. Что ещё надо-то? Качество документации — вот главный пасс-критерий качества кода, и его реально достаточно.
Это, конечно, простой пример, потому что мы все прекрасно знаем, что такое сортировка, но а чем качественно-то отличается любая другая функция от этой? Риторический вопрос. В общем, забудьте и больше никогда не вспоминайте о тезисе, что открытый код якобы надёжней, потому что в него всегда можно заглянуть. Это миф.
Напиши прокси для своих более узкоспециализированных нужд. Собственно любой фрейморк именно это тебе и делает, и выбирая фреймворк, ты не более чем выбираешь комплект сужений имеющейся изначально гибкости. Это же возможно? А как иначе, при таком-то количестве наблюдаемых фреймворков. Это было бы возможно без изначально спроектированной и реализованной гибкости? Отнюдь не факт, всё зависит от потребностей. Вот нет в POSIX гибкой системы секьюрити и межпроцессного взаимодействия, приходится юзать богомерзкие сокеты, проектировать, программировать и отлаживать свои протоколы, строить вокруг него стену из файрвола и правил фильтрации портов и адресов. Ну ок, это ваш выбор. Точнее, вашей ОСи. Ещё точнее – вашего API. Так что наблюдаемое разнообразие фреймворков над WinAPI говорит лишь за то, что я прав. И именно благодаря гибкости WinAPI у вас богатый выбор проксей над ним.
Вот поэтому винда правит крупным бизнесом и домашними ПК, где важны стоимости корпоративных решений и простота администрирования, а POSIX – малым и средним бизнесом, где важны стоимости владений решениями и относительно велики бизнес-риски.

Добавлено 30.04.21, 22:12
Нет, в Комитете решили, что на этот момент существует уже слишком много доСтандартных решений, и так будет гораздо проще рефакторить много легаси. А почему их много, думаю, объяснять не надо: проще было с...лямзить готовый и открытый pthread, чем писать и отлаживать свои самокаты.

Добавлено 30.04.21, 22:32
Пробежаться в цикле тебе и без QVector::fill() было бы несложно, согласись, но коли речь зашла за сервисные функции и методы, то речь идёт об обобщённой задаче, ибо на каждую хотелку методов не напасёшься. Напримерзануляет все, которые при делении на 7 дают в остатке 4. При этом db может быть чем угодно, лишь бы поддерживало модель контейнер+итераторы, и предикат пиши сам, какой нужен. А ещё первым параметром можно указать политику параллельного исполнения, типа там std::execution::parallel_policy, и если в твоей библиотеке оно реализовано, то ок. Ну, не реализовано, ну и ладно, а у кого-то реализовано, и этот код получит профит. Наверно, получит профит... слишком простая задача. Но ведь и гораздо сложнее бывают.
Эм... забей. Слишком много писать объяснений для того, на что ответ я и так представляю.

Добавлено 30.04.21, 22:44
Так её и не используют на высоких нагрузках. Так-то для этого уже мульён лет другие объекты синхронизации предназначены. А вот для чего пользуют (просто пример! пользовать в своих проектах не более чем как демонстрацию концепции):

Добавлено 30.04.21, 22:47
А причём тут права?

Добавлено 30.04.21, 22:50
А зачем было себя ограничивать в интерфейсе, если можно просто написать потомка std::basic_streambuf<> и перекрыть несколько виртуальных методов? И пиши себе стандартными классами хоть в сокеты, хоть в COM:, куда там ты напрограмишь в методах.

https://forum.sources.ru/index.php?showtopic=421325&view=findpost&p=3847045