lock-free - там же всеравно есть атомарные счетчики как минимум? Что мешает дождаться их обнуления в деструкторе? Или прям для каждого потока свой участок памяти?

Как синхронизировать удаление объекта?
Дано: некий объект с двумя методами (назовем их Read() и Write()), работает в агрессивной многопоточной среде, сами методы lock-free
Задача: синхронизировать уничтожение - если объект еще читается или пишется, ждать окончания операций
Гарантируется, что новых обращений не будет, речь о "задолженностях"
Идея лочить shared_mutex в методах и деструкторе кажется крайне сомнительной

Можно hazard pointers посмотреть. Ну или вообще в каком-то виде garbage collection. Мне вот такая идея приходила: например все потоки периодически регать через какой-то callback и ввести инкрементальную эпоху. Тогда можно такой объект кинуть в "мусорку", пометив эпоху, и удалить когда все потоки эту эпоху пройдут.

кажется, вы упускаете, что такое преобразование невозможно
если я еще не засыпаю, то преобразование B* -> D* может содержать арифметику, и записать требуемую арифметическую операцию после чтения поля в указатель на член нельзя

Здравствуйте, господа.
Архитектура вынуждает осуществить явное приведение типов вида
B* C::* -> D* C::* при условии, что B - невиртуальный предок D, а приводимое значение в действительности указывает на поле C типа D* (т.е., по сути, обычный Base* to Derived*, однако, с сохранением информации о том, что сам указатель хранится в поле произвольного C). static_cast и dynamic_cast такого функционала не предоставляет, reinterpret_cast слишком либерален, т.к. готов, согласно 7.6.1.10/10 осуществлять любые приведения вида T1 C1::* -> T2 C2::*, где T1 и T2 либо оба объекты, либо функции. Я что-то упускаю, кроме того факта, что наличие таких приведений в архитектуре в принципе нежелательно?

Как синхронизировать удаление объекта?
Дано: некий объект с двумя методами (назовем их Read() и Write()), работает в агрессивной многопоточной среде, сами методы lock-free
Задача: синхронизировать уничтожение - если объект еще читается или пишется, ждать окончания операций
Гарантируется, что новых обращений не будет, речь о "задолженностях"
Идея лочить shared_mutex в методах и деструкторе кажется крайне сомнительной

Как синхронизировать удаление объекта?
Дано: некий объект с двумя методами (назовем их Read() и Write()), работает в агрессивной многопоточной среде, сами методы lock-free
Задача: синхронизировать уничтожение - если объект еще читается или пишется, ждать окончания операций
Гарантируется, что новых обращений не будет, речь о "задолженностях"
Идея лочить shared_mutex в методах и деструкторе кажется крайне сомнительной

Не упускаю, вроде. Вопрос был лишь в том, как указать компилятору на то, что в действительности по смещению лежит указатель на Derived, а не (topmost) Base. Т.е. никаких операций со значениями выполнять бы не требовалось, а только разрешить использовать интерфейс соответствующего класса.

В примере нет указателей на члены разных классов.

Здравствуйте, господа.
Архитектура вынуждает осуществить явное приведение типов вида
B* C::* -> D* C::* при условии, что B - невиртуальный предок D, а приводимое значение в действительности указывает на поле C типа D* (т.е., по сути, обычный Base* to Derived*, однако, с сохранением информации о том, что сам указатель хранится в поле произвольного C). static_cast и dynamic_cast такого функционала не предоставляет, reinterpret_cast слишком либерален, т.к. готов, согласно 7.6.1.10/10 осуществлять любые приведения вида T1 C1::* -> T2 C2::*, где T1 и T2 либо оба объекты, либо функции. Я что-то упускаю, кроме того факта, что наличие таких приведений в архитектуре в принципе нежелательно?

Там нет счетчиков. Там (почти) классическая очередь Майкла-Скотта

Это надо архитектурой приложения решать, только так. Кто-то должен контролировать работу и удаление этого объекта.
Видимо кто-то, кто загружает его работой

Это невозможно

Как синхронизировать удаление объекта?
Дано: некий объект с двумя методами (назовем их Read() и Write()), работает в агрессивной многопоточной среде, сами методы lock-free
Задача: синхронизировать уничтожение - если объект еще читается или пишется, ждать окончания операций
Гарантируется, что новых обращений не будет, речь о "задолженностях"
Идея лочить shared_mutex в методах и деструкторе кажется крайне сомнительной

щас в коде увидел | оператор, как это нагуглить? не понимаю че это