C++: Многопоточность и объект refcounted

размышление о Вашей проблеме немного..., что Вы говорите, состоит в том, что у Вас есть 1 объект (если refcount равняется 1), и все же 2 потока, оба вызова удаляют () на нем. Я думаю, что это - то, где Ваша проблема действительно заключается.

Наоборот эта проблема, если Вы хотите потоковый объект, который можно безопасно снова использовать между потоками, должна проверить, что refcount больше, чем 1 прежде, чем освободить внутреннюю память. В настоящее время Вы освобождаете его и затем проверяете, является ли refcount 0.

Конечно, каждый поток просто должен справиться с подсчетами ссылок правильно... Таким образом, если ThreadA и ThreadB оба работают с Obj1 затем И ThreadA и ThreadB должны владеть ссылкой на объект, и ОБА должны разъединение вызова, когда они сделаны с объектом.

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

Обратите внимание, что Вы не хотите код, который это работает на самих потоках для вызова AddRef () на объекте, поскольку у Вас затем есть состояние состязания между выпуском вызова потока создания на объекте перед потоками, которые Вы диспетчеризировали для получения шанса выполнить и назвать AddRef ().

Это не ответ, но просто немного совета. В такой ситуации, прежде чем Вы начнете фиксировать что-либо, удостоверьтесь, что можно надежно копировать эти проблемы. Иногда это - простое как выполнение Ваших модульных тестов в цикле некоторое время. Иногда помещение некоторых умных Снов в Вашу программу для принуждения условий состязания полезно.

Касательно подсчета проблем имеют тенденцию задерживаться, таким образом, инвестиции в Вашу тестовую обвязку окупятся в конечном счете.

Любой объект, который Вы совместно используете между потоками, должен быть защищен со взаимным исключением, и то же относится к дескрипторам refcount! Это означает, что Вы никогда не будете удалять последний дескриптор к объекту от двух потоков. Вы могли бы одновременно удалять два отличных дескриптора, которые, оказывается, указывают на один объект.

В Windows Вы могли использовать InterlockedDecrement. Это гарантирует, что точно один из двух декрементов возвратится 0. Только тот поток удалит объект refcounted.

Любой другой поток не мог копировать один из двух дескрипторов также. По общим правилам MT один поток не может удалить объект, все еще используемый другим потоком, и это расширяется на дескрипторы refcount также.

Одно решение состоит в том, чтобы сделать ссылку противостоять атомарному значению, так, чтобы каждый параллельный вызов для уничтожения мог безопасно возобновить только 1 удаление, на самом деле происходящее, другое просто постепенное уменьшение атомарного подсчета ссылок.

Библиотека Intel Thread Building Blocks (TBB) обеспечивает атомарные значения.

Кроме того, поэтому выполняет в библиотеке ACE ACE_Atomic_Op шаблон.

Библиотека Boost обеспечивает библиотеку интеллектуального указателя подсчета ссылок, которая уже реализует это.

http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/a00029.html http://www.boost.org/doc/libs/release/libs/smart_ptr/shared_ptr.htm

Я полагаю, что что-то вдоль этой строки решило бы Вашу проблему:

private:
    void Destroy()
    {

        ACE_Guard< ACE_Mutex > guard( _refCountMutex );  // thread2 are waiting here
        if (_refCount != 0) {
            --(*_refCount);         // This cause a free memory write by the thread2
            if( 0 == *_refCount ) {
                delete _refCount;
                _refcount = 0;
            }
        }
    }
private:
    mutable U32* _refCount;
    mutable ACE_Mutex _refCountMutex;