vector и multithreading

Читать во время записи - UB. Итераторы становятся невалидны.

Лоч его mutex или shared_murtex

наследоваться

От чего? нахера?

От чего?

От std::vector.

нахера?

Чтобы переопределить соответствующие методы и операторы, добавив в них мютексы, семафоры и прочее, в зависимости от того, что ТСу нужно

От чего? нахера?

От вектора. Потому как любой find или erase нужно тоже защищать.. Тогда уж лучше RAII, имхо.

посоны, чо вы несете? какие переопределения? ни find ни esrase не виртуальные методы.

А если писать какие-то свои, то накой наследование вообще нужно?

Да и даже защита find не решит проблему. Потому как find возвращает итератор, а он может сразу стать невалидным, как только покинет область мутекса. Ну и это уж точно не решит проблему использования внешнего алгоритма std::find(v.begin(), v.end(), value)

Делай свой класс, который содержит этот вектор на пару с мутексом, делай поиск, который будет дергать find под мутексом и возвращать уже shared_ptr твой. В нем же делай запись и удаление защищенные. И все будет более красиво выглядеть, чем наследование от вектора.

ни find ни esrase не виртуальные методы.

да в ветора вообще find нет. чот я тут про std::string вспомнил

От вектора. Потому как любой find или erase нужно тоже защищать..

Очень тупая идея. От вектора не нужно наследоваться, так же как и от большинства stl типов. Твой объект не является вектором и имеет семантику типа publish(...), revoke(...), find(pred) - их только и нужно реализовывать, внутри такой объект может быть устроен множеством способов.

Делай свой класс, который содержит этот вектор на пару с мутексом, делай поиск, который будет дергать find под мутексом и возвращать уже shared_ptr твой. В нем же делай запись и удаление защищенные.

Да, чё-то я ступил. Так и сделаю.

tbb concurrentvector

И шаред поинтер по моему тоже не очень тредобезопасный.

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

Велосипедист :)

tbb concurrentvector

Я видел в поиске.. скачал, смотрел этого монстра. Мне это не надо, мне надо всего 3-4 метода.

Да, катаюсь иногда )

А чего монстр? Просто дело в том, что лочить вектор mutex'ами - это создавать лютейший боттл-нэк, который сведет весь мультитрединг на нет. concurrent_vector по заявлениям быстрее и с этой проблемйо разбирается лучше.

concurrent_vector по заявлениям быстрее

Вся суть советчиков на ЛОР. Не знают, но лезут.

concurrent_vector быстрее схемы «1 мутекс на все операции», если потоков больше 2 и есть МНОГО потоков читателей. Если у ТС всего 2 потока, то он будет не только не быстрее, но потенциально медленнее.

Ну и во-вторых. Нет у concurrent_vector метода erase искоробочного, а значит ТСу придется наворачивать свои костыли сверху или переделывать всю свою схему, в которой erase не место. В общем - то это уже попахивает преждевременной оптимизацией и тасканием в проект всякого левого г-на, без которого можно обойтись (по крайней мере пока все не упрется в тот самый ботлнек).

дело в том, что лочить вектор mutex'ами - это создавать лютейший боттл-нэк, который сведет весь мультитрединг на нет

Фейспалм. Откуда ты знаешь, какая там частота взаимодействия?

Не знаю, но потенциально - боттлнэк. А топикстартеру уже решать.

потенциально - боттлнэк

Тогда анонимус правильно сказал об оптимизации.

я бы смотрел в сторону ReadWriteLock

опять этот лоходей... вон из профессии

шел бы ты отсюда букварь читать за ручку с этим толстяком

Read copy update. Но зная тебя нихрена тьі делать не станешь