Привет, подскажите, опреация поиска в мапе, потокобезопасна или нет?

Да

thx!

Некорректный вопрос

Эм, если в другом треде стриггерттся ребалансировка, find вернёт корректное значение?

Ребалансировка при поиске?

Почему это?

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

Потому что зависит от того как используется мапа

Про вставку или очищение я разговор не вёл. Речь шла о поиске

Потому что вопрос не имеет смысла без контекста. Что при этом происходит в других потоках? Безопасна относительно чего?

все верно, это был конкретный вопрос, мапа не изменяется

Что ты понимаешь под "потокобезопасно" ?

ну там вроде одно понятие - при выполнении данной операции одновременно в нескольких потоках, я не получу UB.

Тогда НЕ ПОТОКОБЕЗОПАСЕН.

Но это называется по-другому, "СИНХРОНИЗИРОВАН".

так говорят в общем, типа методы синхронизации потоков, а я говорил про операцию, и говорят, что операцаия безопасна гугл говорит тоже самое и как другие: http://web.mit.edu/6.031/www/fa17/classes/20-thread-safety/

“without additional coordination” means that the data type can’t put preconditions on its caller related to timing, like “you can’t call get() while set() is in progress.”

Так суть одна, что вы мне пытаетесь доказать?

Текст стандарта "The library defines a number of atomic operations (Clause 29) and operations on mutexes (Clause 30) that are specially identified as synchronization operations."

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

Это очевидно. НО БЫЛО СКАЗАННО, что он НЕ ИЗМЕНЯЕТСЯ.

Сейчас не изменяется, потом начнёт изменяться, по твоему свойство операции тоже динамически меняться будет?

Операция thread-safe - это значит, что при попеременном доступе к контейнеру из разных потоков все операции будут работать ОК, То есть, все операции - реэнтерантные. Но это НЕ значит, что контейнер не нужно защищать от ОДНОВРЕМЕННОГО доступа. Нужно, как и любые другие данные.

А как эта писанина относится к С++ вообще?

Этого не подразумевет логика и архитектра программы!

да нет же..

вот тут точно требуется разделение понятий "реентрабельной" и "потокобезопасной" операции

Thread safety: All const member functions can be called concurrently by different threads on the same container. cppreference считает иначе

это конечно какой-то кек-спор рили

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

Это значит, что потокобезопасно юзать const функции над контейнерами (это свойство контейнеров как раз). Нарушение потокобезопасности будет при использовании не-const функции. То есть свойство не меняется динамически как ты сказал, оно остаётся.

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

Давай перейдём из философо-терминологической плоскости в сугубо практическую. Привет, подскажите, опреация поиска в мапе, потокобезопасна или нет? Поиск в одном и том же словаре МОЖНО производить из разных потоков управления. При этом НУЖНО ГАРАНТИРОВАТЬ, чтобы во время поиска никто словарь не менял.

Да, это я прекрасно понятно. ПОЭТОМУ И НАПИСАННА КОНКРЕТНАЯ ОПЕРАЦИЯ!

Ну, так что ещё не ясно? Или может ещё кому-то не ясно?

ну мне все было ясно уже давно

Это значит, что в общем случае эти const функции не являются потокобезопасными.

Являются.

Ну смотри, ты с определением потокобезопасности операции выше в http://web.mit.edu/6.031/www/fa17/classes/20-thread-safety/ согласен?

Нет. Даже читать не хочу. Оно как к С++ относится?

Это было вообще к теме то как именовать операцию синхронизированной или безопасной

Ну в стандарте С++ же нет определения потокобезопасной операции вроде как, поэтому надо его взять откуда-нибудь и применить к нашему случаю.

Ну вроде как есть. Правда, лень искать...

с C++11 должно быть все-таки, не такими словами, но должно

Ну вот в cppreference есть