Manager + shared

[Igors]

Добрый день

Вот разбираюсь в обильном чужом коде. Есть система "менеджеров" (читай синглтонов) которые хранят мапы имя->объект одного типа. Пример

Код

C++ (Qt)
// создаем skeleton
Skeleton * sk1  = new Skeleton("Skeleton 1");
 
// регистрируем его в менеджере
scene->getSkeletonManager()->addSkeleton(sk1);
 

Теперь мы можем брать объект по имени и удалять его

Код

C++ (Qt)
Skeleton * sk =  scene->getSkeletonManager()->getSkeleton("Skeleton 1");
scene->getSkeletonManager()->removeSkeleton("Skeleton 1");
 

Подобную организацию я видел не раз, не скажу что это "плохо".

НО - тут же начинаются пляски с шаред пойнтером. Вот меня это как-то смутило. Ведь если "менеджер" берет на себя "ownership" то все удаления должны идти через него. С др стороны шаред грохнет если ноль ссылок.

Как Вы думаете - могут эти 2 подхода "мирно сосуществовать"? Или это несомненно "косяк архитектуры"?

Спасибо

[Racheengel]

Если деструктор Skeleton корректно сообщает менеджеру о своей "смерти", то все ок.

[ssoft]

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

Если возможен многопоточный доступ к менеджеру, то такой указатель в любой момент может стать невалидным (из-за возможности удаления) и это "косяк архитектуры". Если заменить простые указатели на shared_ptr, то это решит проблему с валидностью объекта, но может создать проблемы (не обязательно) с перекрестными ссылками. Поэтому лучше вместо простых указателей использовать weak_ptr, преобразуя их в shared_ptr во время работы с объектом.

В данном случае - если многопоточный доступ отсутствует, то в данных ограничениях решение валидное; если многопоточный доступ присутствует, то имеется "косяк архитектуры".

[Racheengel]

В данном случае - если многопоточный доступ отсутствует, то в данных ограничениях решение валидное; если многопоточный доступ присутствует, то имеется "косяк архитектуры".

Тогда это будет косяк имплементации, а не архитектуры.
С "архитектурой" тут проблем нет.

[ssoft]

Тогда это будет косяк имплементации, а не архитектуры.
С "архитектурой" тут проблем нет.

Согласен

[Igors]

"Многопоточность" отсутствует.

Поэтому лучше вместо простых указателей использовать weak_ptr, преобразуя их в shared_ptr во время работы с объектом.

Если имеется ввиду "менеджер хранит weak_ptr", то

1) Сейчас менеджер грузит объекты не заботясь о том кто их юзает (может пока и никто). Чем заменить этот ф-ционал если он хранит weak?

2) Что делать с

Код

C++ (Qt)
scene->getSkeletonManager()->removeSkeleton("Skeleton 1");

? Через weak_ptr никого не удалить

В общем так менеджер теряет ownership и становится чем-то типа "наблюдающего" (пусть и полезного)

[Igors]

Если деструктор Skeleton корректно сообщает менеджеру о своей "смерти", то все ок.

Житейски разумно, но явно "не айс" (як каже молодь). Чего это "младший" дает указания "менеджеру", вообще чего он знает о существовании менеджера?

И это не решает коллизии "менеджер грохает используемого"

[ssoft]

Если имеется ввиду "менеджер хранит weak_ptr", то ...

Ни в коем случае). Менеджер хранит shared_ptr, а вот предоставляет weak_ptr. Тогда в месте использования можно усилить weak_ptr до shared_ptr и локально контролировать время жизни объекта. Даже если менеджер удалит объект, грохнется он только после удаления последнего shared_ptr.

[Racheengel]

Чего это "младший" дает указания "менеджеру", вообще чего он знает о существовании менеджера?

Менеджер при создании объекта "говорит" ему, кто хозяин:

Skeleton* Manager::AddSkeleton()
{
  Skeleton* slave = new Skeleton();
  slave->setParent(this);
  return slave;
}

А при смерти slave в этом случае он просто получает информацию о событии:

Skeleton::~Skeleton()
{
  if (m_parent)
    m_parent->slaveKilled(this);
}

Тогда никаких проблем не возникнет.

И это не решает коллизии "менеджер грохает используемого"

Тогда менеджер просто получит вызов slaveKilled с поинтером на прибиваемый объект, но он же об этом в курсе

[_Bers]

Добрый день
Как Вы думаете - могут эти 2 подхода "мирно сосуществовать"? Или это несомненно "косяк архитектуры"?

да. могут.
shared_ptr позволяет гибкие стратегии владения ресурсами.

[_Bers]

Даже если менеджер удалит объект, грохнется он только после удаления последнего shared_ptr.

не факт.
зависит от бизнес-логики менеджера.

[Igors]

да. могут.
shared_ptr позволяет гибкие стратегии владения ресурсами.

К слову: а по-моему с гибкостью у него проблемы. Напр я рассчитывал на удаление объекта, но по каким-то причинам его нет. Как узнать "кто держит"?

Ну ладно, так что - менеджер должен хранить (вместо обычных указателей как сейчас)

Код

C++ (Qt)
typedef std::map<std::string, shared_ptr<Skeleton> > TMap;

Тогда все что попало в менеджер остается неубиенным. А если менеджер удалит свой шаред из мапы - еще хуже: значит объект уже загружен, а в менеджере его нет - действующий через менеджер вероятно загрузит еще копию. Где же (гибкая) стратегия владения?

[Igors]

И это не решает коллизии "менеджер грохает используемого"

Тогда менеджер просто получит вызов slaveKilled с поинтером на прибиваемый объект, но он же об этом в курсе

Менеджер не в курсе в каком(их) шаред пойнтере хранится этот поинтер

Менеджер при создании объекта "говорит" ему, кто хозяин:

Skeleton* Manager::AddSkeleton()
{
  Skeleton* slave = new Skeleton();
  slave->setParent(this);
  return slave;
}

А при смерти slave в этом случае он просто получает информацию о событии:

Skeleton::~Skeleton()
{
  if (m_parent)
    m_parent->slaveKilled(this);
}

Тогда никаких проблем не возникнет.

Есть одна система управления/ownership  (менеджер). Вы предлагаете добавить еще другую (parent-child).. Это будет работать только в случае m_parent == manager. Тогда зачем заводить m_parent, slaveKilled и.т.п. если можно действовать через тот же синглтон

Код

C++ (Qt)
Skeleton::~Skeleton( void )
{
 ...
 scene->getSkeletonManager()->takeSkeleton(this->getName());
}
 

[Авварон]

Где же (гибкая) стратегия владения?

shared+weak в манагере.

Код:

{
    auto newSkeleton = std::make_shared<Skeleton>();
    manager->addSkeleton(newSkeleton, "name");
}

{
    auto skeleton = manager->getSkeleton("name");
    manager->removeSkeleton("name"); // skeleton всё еще держит овнершип
    auto skeleton2 = manager->getSkeleton("name");
    Q_ASSERT(skeleton == skeleton2); // true, манагер хранит вик на старый скелетон и вернет нам его
}

{
    auto newSkeleton = std::make_shared<Skeleton>();
    manager->addSkeleton(newSkeleton, "name"); // а вот тут засунули новый инстанс, можно ругаться, если вик ещё живой
    auto skeleton = manager->getSkeleton("name");
    Q_ASSERT(skeleton == newSkeleton);  // этот скелетон не равен тому, что был в предыдущем скопе
}

[_Bers]

да. могут.
shared_ptr позволяет гибкие стратегии владения ресурсами.

К слову: а по-моему с гибкостью у него проблемы. Напр я рассчитывал на удаление объекта, но по каким-то причинам его нет. Как узнать "кто держит"?

Ну ладно, так что - менеджер должен хранить (вместо обычных указателей как сейчас)

Код

C++ (Qt)
typedef std::map<std::string, shared_ptr<Skeleton> > TMap;

Тогда все что попало в менеджер остается неубиенным. А если менеджер удалит свой шаред из мапы - еще хуже: значит объект уже загружен, а в менеджере его нет - действующий через менеджер вероятно загрузит еще копию. Где же (гибкая) стратегия владения?

ничего не понял.
что значит "рассчитывал на удаление объекта" ?

http://www.cyberforum.ru/cpp-beginners/thread1500101.html#post7882976