Это плохая идея получить блокировку в деструкторе?

Нет ничего плохого в том, чтобы заблокировать мьютекс в деструкторе. Например, может потребоваться сделать общие ресурсы потокобезопасными. Таким образом, для освобождения права собственности на общий ресурс может потребоваться блокировка мьютекса. Если бы RAII просто развалился в многопоточном программировании, это был бы не очень полезный инструмент. Действительно, доступ к блоку управления std::shared_ptr является потокобезопасным, в том числе при уменьшении счетчика ссылок во время уничтожения общего указателя. По-видимому, это обычно реализуется с помощью атомарных операций, а не блокировки мьютекса (не цитируйте меня по этому поводу), но контекст тот же: вы освобождаете право собственности на общий ресурс во время уничтожения, и это должно быть записано в потокобезопасный способ.

Однако имейте в виду: блокировка мьютекса может вызвать исключение, и вы должны (почти) всегда поглощать исключения в деструкторах с помощью try/catch. В противном случае, если стек уже раскручивается из-за другого исключения, программа завершится немедленно и безвозвратно, независимо от того, оборудован ли вызывающий код для поглощения исходного исключения и/или исключения деструктора.

Но может быть способ реструктурировать ваш код, чтобы полностью избежать проблемы: Bar на самом деле не нужна ссылка на Foo; нужен только int. В вашем коде Bar запрашивает int у заданного Foo. Когда Bar уничтожается, ему нужно вернуть int обратно Foo, чтобы его можно было переработать; для этого требуется хранить внутреннюю ссылку на Foo на протяжении всего его жизненного цикла, чтобы он мог взаимодействовать с ним во время уничтожения. Вместо этого рассмотрите возможность отдать intBar непосредственно при строительстве и забрать int у него при разрушении. Это движущий принцип внедрения зависимостей, который представляет собой букву «D» в слове «SOILD». Следовательно, он приносит с собой все типичные преимущества внедрения зависимостей (например, улучшение тестируемости класса Bar).

Например, эту логику можно отследить в более крупном классе, который управляет объектом Foo вместе со всеми связанными с ним объектами Bar. Вот некоторый псевдокод, но точные детали интерфейса будут зависеть от вашего приложения:

class BarPool:
    Foo foo;
    Map<int, Bar> bars;
    mutex m;

    BarPool(Foo foo) : foo(foo) {}

    int add_bar():
        lock m;
        // Note: foo.pop() should probably be made thread-safe
        // by internally locking / unlocking foo's mutex
        int i = foo.pop()
        bars.add(i, new Bar(i));
        unlock m;
        return i

    void remove_bar(int i):
        lock m;
        // foo.push() should also probably be made thread-safe
        bars.remove(i)
        foo.push(i)
        unlock m;

    ...