Refcountet smartpointer race condition

Ruvi

Hi,

ich habe mal eine Frage ich versuche gerade rauszufinden wie der std::shared_ptr<>
funktioniert und im DTOR vom shared ptr wird _Decref() aufgerufen und decref macht das:

void _Decref()
		{	// decrement use count
		if (_MT_DECR(_Mtx, _Uses) == 0)
			{	// destroy managed resource, decrement weak reference count
			_Destroy();
			_Decwref();
			}
		}

Ist die Abfrage nicht eine Race Condition? Was passiert, wenn nach der Abfrage (_== 0) in einem anderen Thread gerade ein Objekt erstellt wird bevor _Destroy() und _Decwref() aufgerufen wird?
Müsste die Funktion nicht mit einem mutex geschuetzt werden oder wenigsten volatile definiert werden?
Ich bin gerade ein wenig verwirrt, vielleicht kann ja jemand Licht ins Dunkel bringen.

P.S.:Visual Studio 2013

Ruvi schrieb:

Ist die Abfrage nicht eine Race Condition? Was passiert, wenn nach der Abfrage (_== 0) in einem anderen Thread gerade ein Objekt erstellt wird bevor _Destroy() und _Decwref() aufgerufen wird?

Das geht nicht. Wenn du nach _MT_INCR googlest stellst du fest, dass das eine lockfreie Dekrementierung vornimmt. Das hat den Effekt von

lock()
--Uses;
int the_uses = Uses;
unlock();
if (the_uses==0) {
 _Destroy();
 _Decwref();
}

Wo soll da ein Objekt erstellt werden können? Vor dem lock ist es egal. Nach dem unlock ist uses==0, was es verbietet, das Objekt zu erstellen.

Ruvi

mutex_inkrement schrieb:

Wo soll da ein Objekt erstellt werden können? Vor dem lock ist es egal. Nach dem unlock ist uses==0, was es verbietet, das Objekt zu erstellen.

Ah, mir war nicht bewusst, das uses==0 eine Konstruktion verhindert, aber macht Sinn, danke.

Noch eine interessante Info warum der weak reference count runtergezählt wird: https://www.reddit.com/r/cpp/comments/3eia29/stdshared_ptrs_secret_constructor/ctfeh1p

Ruvi schrieb:

... wenigsten volatile definiert werden?

volatile hat nichts mit Threads zu tun.