Для неосиливших структурированную документацию, избегающую дублирование сущностей:

The expression m.lock() has the following properties

Behaves as an atomic operation. Blocks the calling thread until exclusive ownership of the mutex can be obtained.

Наверное, потому что они части интерфейса объекта, который следует семантике класса этого обьекта.

Кто на ком стоял?

Точно я?

Да. Ты сказал, что гарантии implementation defined. Я тебе показал, что для pthreads гарантии строгие. Теперь ты мне говоришь, что для shared_lock «такие же», т.е. тоже строгие.

Так implementation defined или стандарт строго гарантирует? Определись.

Ты троллишь или правда настолько невменяем?

И где тут хоть одно слово про голодание? Даже в крестовом концепте есть ограничение на облом читателей.

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

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

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

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

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

Видимость чего, Йорик?

но есть ли тогда смысл писать именно на плюсах?

zero-cost обёртки позволяют добавлять контроль над рантаймом и простотой написания кода, по сравнению с C. под zero-cost понимать действительно zero-cost, т.е. когда сгенерированный машинный код совпадает.

незаменим только CAS. остальное заменимо.

в debug сборке будут? в остальный случаях не наблюдаются. компилирую часто с --save-temps, так что знаю о чём говорю.

visibility (w -> r). не знаю как на вашем языке это называется.

Мне кажется, ты упорот beyond repair.

я понимаю, что такое зеро-кост. но вопрос: нужно ли оно? «простоты написания кода» в кернеле и вокруг него как-то не наблюдается. там проблемы другого уровня.
кстати, зеро-кост типизация в С делается через обычные структуры. сама пользую, но только не в системном программировании (там нет таких необозримых объёмов кода, чтобы это было нужно). зато если есть мегапортянки кода на сишечке, где есть угроза случайно смешать типы из-за множества разных файлов и библиотек, оборачиваешь их в структурки - и вуаля! структурка на этапе компиляции схлапывается, но пока компиляция идёт, компилятор ни за что не разрешит смешать такие типы. дёшево и сердито.

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

те люди, которые кодят в ядре, давно вышли из возраста, когда себе ноги случайно отстреливают.

И именно поэтому у нас нет никаких дыр в ядре, ага.

мне кажется, что ты не очень знаешь о чём говоришь. или не понимаешь что означают термины atomicity, visibility, ordering

Знаю и понимаю. Только всё это относится к более низким уровням абстракции, чем те, которые обсуждаются. Размахивание этими терминами здесь - либо упоротость, либо желание показаться умным.

есть звездёж, а есть просто факты. я придерживаюсь фактов

В самом деле? Ну окей.

я понимаю, что такое зеро-кост. но вопрос: нужно ли оно?

кому не нужно, тот может смело писать на подмножестве C (или любом другом, которое ему нужно) в C++ или просто на C. мне C++ позволяет писать лучше, а выхлоп компилятора я контролирую.

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

Ради интереса, струтктры - это типа такого?

typedef struct { void * Impl_ ; } some_t ;

some_t some_create  ( void              ) ;
void   some_destroy ( some_t const Some ) ;

это те абстракции, которые «протекают» сквозь все примитивы и фреймворки. например, в async таске поменял глобальную переменную - поимел data race. всё это очень регулярно наблюдается во время code review, хотя люди очень стараются пользоваться высокоуровневыми библиотеками примитивов.

повторюсь - atomicity, visibility, ordering - это то, что нужно уметь сохранить несмотря ни на какой уровень абстракции. для простых задач это тривиально - типа разбить массив на кусочки и запустить в каком-нибудь std::async в n потоков, а потом собрать результат. для менее тривиальных связь прослеживать нужно.

короче да - высокоуровневые примитивы помогают иметь меньше гемора с кодированием, но при этом корректность кода нужно уметь показывать. примитивы сами по себе этого не гарантируют.

кхмм... «потери производительности»? чьей? твоей или процессора? в этом и разница.

да, типа такого. удобно применять, когда есть километры кода (особенно не твоего). недавно у меня выплыла задачка: переписать очень объёмный код на сях на два вида сокетов. кроме обычных сокетов появились, скажем так, принципиально другие сокеты, через которые нужно было зарулить часть обращений, а часть оставить на стандартных кернельных. у новых сокетов были свои API, но идентификаторы такие же int'овые. обращений к разным сокетам в приложении было просто дохрена. не сойти с ума помогли именно обёртки из структур. чтобы один int отделить от другого.

ты с'эмулировала врукопашную небольшой кусочек крестов. пирожок теперь тебе за это дать?

процессора. говорю же, смотрю, что генерирует компилятор, чтобы там ничего лишнего не было.

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

Ты уже устала тут нудеть...

Выкини эксепшены (можно ещё rtti, но необязательно) и на C++ можно писать такой же по производительности код, как на C, если не более производительный (т.к. компилятор может иметь больше информации о типах и агрессивнее инлайнийть. погугли про std::sort vs qsort). Только писать будет удобнее и безопаснее благодаря шаблонам, raii и проч.

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

а то я не в курсе! но не нужно это в большинстве задач, с которыми мне приходится работать. и особенно не нужно в системном программировании. мне пофигу, на чём там гуй стряпают. но в серьёзном программировании а-ля системное или серверное пока бардака нет. и это очень хорошо, что нубы держатся от него подальше. отсутствие нубских «удобств» служит дополнительной защитой от дурака.

особенно не нужно в системном программировании

Так и запишем: «писать более производительный код в системном программировании не нужно».

нет. производительность и безопасность кода - это в голове, а не в компиляторе. нубам не понять.
и прямым доказательством тому - сравнение производительности кернела, где каждый байт учитывается, и поделий гуеплётов, которые жрут гигабайты впустую (зато не надо заморачиваться с кодом, ведь всё должно быть просто). это банальные и очевидные вещи. компилятор идиотам не поможет. а умный человек и ассемблер может использовать по делу.

производительность и безопасность кода - это в голове, а не в компиляторе

Так и запишем: «инлайнинг делает голова, а не компилятор».

и прямым доказательством тому - сравнение производительности кернела, где каждый байт учитывается

Уж не линуксового ли кёрнела? Где O(1)-планировщик запилили вчера, а big kernel lock выпилили только-только.

Где O(1)-планировщик запилили вчера, big kernel lock выпилили только-только.

15 лет назад, а как вчера %)

это к вопросу о необходимости изобретения каких-то новых велосипедов

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

это не кусочек компилятора. это мозг. опять же, нубам не понять. им мозг заменяет компилятор.

и ведь не поспоришь... тебе, например, мозг заменяет компилятор си :)

нет. производительность и безопасность кода - это в голове, а не в компиляторе.

можно ли увидеть код на C, который на C++ нельзя написать так же эффективно или эффективнее? единственное, что могу придумать - это пример с restrict.

Когда хотят rwlock, то подразумевают некоторые гарантии защиты от starvation для reader-ов и/или writer-ов. Обычно для writer-ов: потоки не смогут получать доступ на чтение, если есть writer-ы, ждущие доступа на запись.

Хотят такие гарантии только когда не умеют пользоваться rwlock и блокировками вообще. Если за мьютекс постоянно борятся 2+ нити — надо либо разбивать то что защищает мьютекс на части, либо пользоваться другим паттерном синхронизации типа очередей или атомиков.

про std::sort vs qsort

При чем тут компилятор? В любой реализации qsort ввиде макроса или header-only функции на сишке все так же инлайнится.

Если за мьютекс постоянно борятся 2+ нити

То возникает вопрос - а что такого можно написать в юзерспейсе, чтоб нити не делали практически ничего полезного, кроме как бороться за мьютекс?

(это в поддержку вашего поста)

можно ли увидеть код на C, который на C++ нельзя написать так же эффективно или эффективнее?

Дело не в том. Сишка, она про написание руками + можно навесит абстракций, аки глиб/гобджект. Кресты же — изначально нагромождение абстракций со строками, срущими в кучу, функциональными объектами, методами, вызывающимися неявно (например, деструкторы, на которые жаловался кармак) и проч.

Вопрос не в том, где можно писать производительный код. Авторы fftw и чуваки из jane street на окамле умудряются такой код писать, что он обгоняет крестоальтернативы. На фортране так вообще можно очень производительный код писать — спасибо компиляторам.

Но вопрос в том, где проще писать низкоуровневый код. На сишке конечно же проще писать низкоуровневый код, ибо она проще, прозрачнее и ближе к железу.

методами, вызывающимися неявно (например, деструкторы, на которые жаловался кармак)

Ну, офигеть теперь. Он действительно где-то на это жаловался?

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

Ну, офигеть теперь.

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

http://number-none.com/blow/john_carmack_on_inlined_code.html

Такой вот харкорный эмбеддед.

http://www.roboticstomorrow.com/story/2014/12/john-carmack-on-modern-c/5262/

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

например, в async таске поменял глобальную переменную - поимел data race

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

Такой вот харкорный эмбеддед.

http://www.roboticstomorrow.com/story/2014/12/john-carmack-on-modern-c/5262/

Ну и где там хардкор? Вот, одна из статей, на которую ведет ваша ссылка: Lessons to learn from Oculus development team when using the “Modern C++” approach. Складывается впечатление, что команда Кармака в разработке Oculus SDK начала использовать тот C++, который начали рекомендуется с момента выхода C++98. Называть это в 2015-ом году «Modern C++» как-то странно.

Кроме того, в свете упоминавшихся выше деструкторов, особо пикантно в статье смотрится раздел «5- Allocation and RAII».

Хотят такие гарантии только когда не умеют пользоваться rwlock

Ну давай, просвети нас, как же надо пользоваться rwlock.

Если за мьютекс постоянно борятся 2+ нити

Ты какие-то свои проблемы спроецировал на мой мессадж и бросился с ними воевать.

Сишка, она про написание руками + можно навесит абстракций, аки глиб/гобджект.

Глиб/гобджект лучше не навешивать.

Кресты же — изначально нагромождение абстракций

Открою тебе секрет: все абстракции плюсов написаны руками, как и для сишки.

со строками, срущими в кучу

Не осилил аллокаторы — это C++ виноват.