Linux — C ++ SIGABRT в деструкторе структуры в многопоточном приложении

Мне нужна помощь в разгадывании многопоточности.

У меня есть приложение с посредником, скажем:

class Mediator{
ConfigMgr * mgr;
....
Config getConfig(){
return mgr->getConfig();
};
};

ConfigMgr правильно инициализирован, никаких проблем с ним нет. Он состоит, среди прочего, из схемы Config, которая представляет собой структуру, которая имеет некоторые логические значения и std :: strings:

struct Config{
std::string param1;
std::string param2;
....
}

class ConfigMgr {
Config blueprint;

Config getConfig(){
Lock l(mtx); //wrapper on POSIX mutex and lock, works as expected
refreshConfig(); // some stuff that might alter Config blueprint
return config;
}

}

Наконец, у меня есть несколько рабочих потоков, которые иногда нужно вызывать
mediator->getConfig().param1;

Проблема в том, что время от времени мое приложение падает с SIGABRT. Из того, что я смог определить, происходит сбой при двойном удалении строки в деструкторе Config:
Config::~Config()
Структура не имеет методов, написанных мной.

Я не могу отследить первопричину. Моя структура Config всегда передается копией, а не ссылкой. Я думаю, что каждый поток должен иметь свою собственную копию Config с момента вызова ConfigMgr :: getConfig (). Эта конструкция должна быть ориентирована на многопотоковое исполнение, но, безусловно, существует какое-то состояние гонки. Ребята, у вас есть какой-нибудь совет?

1

Решение

Я был поражен этим. Важные вещи для запоминания:

  1. std :: string разделяет свой буфер char * при копировании.
  2. std :: string не предназначен для многопоточности.

Поэтому вы нажимаете несколько строк std :: strings в разных потоках, пытаясь удалить один и тот же буфер, который, по их мнению, следует удалить из-за неправильного обновления переменных подсчета ссылок.

Вероятно, вам нужно будет более четко указать нужные вам строковые копии и определить конструктор копирования для объекта Config.

0

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]