Thread-safe shared_ptr , Реализация потоко-безопасного SharedPtr

[Олег М]

Нет, не так. Здесь первый поток ресетит shared_ptr, sp, и присваивает его weak_ptr'у, sp2. Второй поток вызывает weak_ptr::lock, те создаёт новый shared_ptr, и, если он не null, обращается к его содержимому. Для std::shared_ptr это не работает, для CSharedPtr всё нормально

[ЫукпШ]

Олег М, вот какая проблема с многопотоковостью SP.
1. Несколько экземпляров SP указывают на объект выбранного типа.
2. Другие несколько экземпляров - на другой объект этого-же типа.
3. SP - это шаблонный класс. Значит, возможно наличие групп SP,
указывающих на объекты любых других типов.

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

[Flex Ferrum]

Цитата Олег М @ 20.01.17, 15:17

Нет, не так.

Смотри.
Строчка 9:

Цитата Олег М @ 17.01.17, 13:40

threads.emplace_back(std::make_unique<std::thread>([&sp, &sp2, &stop]()

- ты передаёшь в поток оба указателя по ссылке.

Строчка 13:

Цитата Олег М @ 17.01.17, 13:40

sp.reset(new std::string("!!!!!!!!!!!!!!!!!!!!!!!!!!!!11111111111111111111111111111111111111"));

Ты в нескольких потока одновременно модифицируешь один и тот же shared_ptr. То есть незащищённый конкурентный доступ к внешнему ресурсу.

Строчка 14:

Цитата Олег М @ 17.01.17, 13:40

sp2 = sp;

Ты так же конкурентно (как и в предыдущей строке) модифицируешь разделяемый weak_ptr. Один и тот же во всех потоках.

Строчка 18:

Цитата Олег М @ 17.01.17, 13:40

threads.emplace_back(std::make_unique<std::thread>([&sp2, &stop]()

Передаёшь ещё в один поток ссылку на внешний weak_ptr.

Строчка 18:

Цитата Олег М @ 17.01.17, 13:40

auto sp = sp2.lock();

Пытаешься залочить внешний weak_ptr, который активно (без синхронизации) меняется из соседнего потока.
Ты, конечно, можешь ожидать, что будет создана отдельная копия shared_ptr'а на какой-то указатель, но если повезёт, твоя программа свалится с внятной диагностикой. Ибо тут самый что ни наесть типовой data race. Если не повезёт - отправится SMS на адрес Трампа и он нажмёт на красную кнопку в своём ядерном чемоданчике. Undefined Behavior - он такой.

Сообщение отредактировано: Flex Ferrum - 20.01.17, 15:36

[Олег М]

Имеешь ввиду template <typename T> CSharedPtrLock &GetSharedPtrLock() и, соответственно, CSharedPtrBase::GetSharedRef()?

Добавлено 20.01.17, 15:42
Flex Ferrum

Цитата Flex Ferrum @ 20.01.17, 15:34

Ты, конечно, можешь ожидать, что будет создана отдельная копия shared_ptr'а на какой-то указатель, но если повезёт, твоя программа свалится с внятной диагностикой. Ибо тут самый что ни наесть типовой data race. Если не повезёт - отправится SMS на адрес Трампа и он нажмёт на красную кнопку в своём ядерном чемоданчике. Undefined Behavior - он такой.

Ну, во-первых не сваливается, работает. Во-вторых как раз эти функции и являются потоко-безопасными. Я там не ожидаю, я точно знаю, что будет создано return CSharedPtr<T>(GetSharedRef<T>());

Добавлено 20.01.17, 15:43
ЫукпШ Имеешь ввиду template <typename T> CSharedPtrLock &GetSharedPtrLock() и, соответственно, CSharedPtrBase::GetSharedRef()?
Очень похоже на адский косяк, сижу, думаю

[Flex Ferrum]

Цитата Олег М @ 20.01.17, 15:38

Ну, во-первых не сваливается, работает.

Я говорю про работу с shared_ptr. Как аргумент к тому, что конкретно этот пример разделяемым ресурсом считает сам указатель (CSharedPtr/CWeakPtr в твоей терминологии), а не CSharedPtrBase.

[Олег М]

Цитата Олег М @ 20.01.17, 15:38

Пытаешься залочить внешний weak_ptr, который активно (без синхронизации) меняется из соседнего потока.

Вообще, там вроде всё синхронизируется, в конструкторах/деструкторах

[Flex Ferrum]

Цитата Олег М @ 20.01.17, 15:47

Вообще, там вроде всё синхронизируется, в конструкторах/деструкторах

В стандартном? Нет. Не лочится. И не должно - это не требуется стандартом. А работа с атомиками (как я уже говорил) - это не локи. Это просто работа с атомиками.

[Олег М]

Цитата Олег М @ 20.01.17, 15:47

Я говорю про работу с shared_ptr. Как аргумент к тому, что конкретно этот пример разделяемым ресурсом считает сам указатель (CSharedPtr/CWeakPtr в твоей терминологии), а не CSharedPtrBase.

Доступ к самому указателю синхронизируется при помощи счётчика CSharedCounter. Что именно неправильно, и как должно быть?

Добавлено 20.01.17, 15:54

Цитата Flex Ferrum @ 20.01.17, 15:50

В стандартном? Нет. Не лочится. И не должно - это не требуется стандартом. А работа с атомиками (как я уже говорил) - это не локи. Это просто работа с атомиками.

В стандартном да, не работает. Я где-то видел, что они планируют, сходу не могу найти где. У меня вроде работает. Работа с атомиками - это lock-free блокировка, чем то-хуже, чем-то лучше мьютексов.

[Flex Ferrum]

Цитата Олег М @ 20.01.17, 15:51

Доступ к самому указателю синхронизируется при помощи счётчика CSharedCounter. Что именно неправильно, и как должно быть?

Ещё раз: я говорю про работу этого кода с std::shared_ptr/std::weak_ptr.

Добавлено 20.01.17, 15:56

Цитата Олег М @ 20.01.17, 15:51

В стандартном да, не работает. Я где-то видел, что они планируют, сходу не могу найти где. У меня вроде работает. Работа с атомиками - это lock-free блокировка, чем то-хуже, чем-то лучше мьютексов.

Работа с атомиками - это работа с атомиками. То есть работа с памятью с учётом особенностей многопоточной и многопроцессорной среды. Но не более того. Рассматривать это как блокировку (или варианты блокировки) - это обманывать самого себя.

[Олег М]

Цитата Flex Ferrum @ 20.01.17, 15:54

Ещё раз: я говорю про работу этого кода с std::shared_ptr/std::weak_ptr.

Я ж вроде и говорил, что он не работает, именно поэтому пришлось писать свои классы. И?

[Flex Ferrum]

Цитата Олег М @ 20.01.17, 15:57

И?

Я до сих пор не догоняю, какая именно реальная задача решается таким вот сценарием:

Цитата Олег М @ 20.01.17, 15:17

Здесь первый поток ресетит shared_ptr, sp, и присваивает его weak_ptr'у, sp2. Второй поток вызывает weak_ptr::lock, те создаёт новый shared_ptr, и, если он не null, обращается к его содержимому. Для std::shared_ptr это не работает, для CSharedPtr всё нормально

[Олег М]

Цитата Flex Ferrum @ 20.01.17, 15:54

Работа с атомиками - это работа с атомиками. То есть работа с памятью с учётом особенностей многопоточной и многопроцессорной среды. Но не более того. Рассматривать это как блокировку (или варианты блокировки) - это обманывать самого себя.

Ну почему обманывать, у lock-free алгоритмов есть масса преимуществ, особенно на многопроцессорных серверах. Есть и свои недостатки. Я в них не особо разбираюсь, поэтому в данном случае мне больше нравится, что они занимают много меньше памяти - 8 байт против 40 для мьютекса

Добавлено 20.01.17, 16:04
Реальная задача чуть позже. Надо как-то сформулировать. Запустил-таки всю эту бадягу на боевом сервере, наблюдаю, не могу толком ни на чём другом сосредоточиться

[Flex Ferrum]

Цитата Олег М @ 20.01.17, 16:02

Ну почему обманывать, у lock-free алгоритмов есть масса преимуществ, особенно на многопроцессорных серверах.

lock-free-алгоритмы - это одно из средств применения атомиков. Причём весьма специфичная. Средствами синхронизации атомики от этого не становятся.

[Олег М]

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

[Flex Ferrum]

Цитата Олег М @ 20.01.17, 16:25

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

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