ich habe einen Anwendungsfall, wo ich in einer Klasse A und der Methode methodInA(int b) eine statische Variable C habe.

Die statische Variable ist durch einen Mutex geschützt und wird mit b initialisiert.

Danach wird mit set.find(C) gesucht.

Nun kracht es mit assert in der xtree C++Lib bei der Suche. find() scheitert in _DEBUG_LT_PRED.

Meine Vermutung ist, dass zwar die Methode methodInA() exklusiv geschützt ist, aber dadurch das C statisch ist, über mehrere Klassen-Instanzen geteilt wird.

Bei der Suche im std::set wird offensichtlich die statische Variable C verändert, was die Assterion auslöst.

Ist das zutreffend?

Die statische Variable ist durch einen Mutex geschützt und wird mit b initialisiert.

D.h. sie ist immer b? Und warum dann set.find(C) anstatt set.find(b)?

set.find(C)

Die Klassen der STL sind nicht threadsafe.

Ist das zutreffend?

Wahrscheinlich nicht.

Wahrscheinlich nicht.

Doch, doch, das ist zutreffend. Das Problem ist nämlich, dass ein Thread die statische Variable ändert.

Danach scheitert der Code an dieser Stelle.

// TEMPLATE FUNCTION _Debug_lt_pred
template<class _Pr, class _Ty1, class _Ty2> inline
	bool _Debug_lt_pred(_Pr _Pred,
		const _Ty1& _Left, const _Ty2& _Right,
		_Dbfile_t _File, _Dbline_t _Line)
	{	// test if _Pred(_Left, _Right) and _Pred is strict weak ordering
	if (!_Pred(_Left, _Right))
		return (false);
	else if (_Pred(_Right, _Left))
		_DEBUG_ERROR2("invalid operator<", _File, _Line);
	return (true);
	}

knivil schrieb:

Wahrscheinlich nicht.

Doch, doch, das ist zutreffend. Das Problem ist nämlich, dass ein Thread die statische Variable ändert.

Danach scheitert der Code an dieser Stelle.

Die Ordnungsrelation des sets hängt von C ab?

Stefan124 schrieb:

knivil schrieb:

Wahrscheinlich nicht.

Doch, doch, das ist zutreffend. Das Problem ist nämlich, dass ein Thread die statische Variable ändert.

Danach scheitert der Code an dieser Stelle.

Die Ordnungsrelation des sets hängt von C ab?

Die Ordnung nicht, aber sehr wohl die Suche.

Die Ordnung nicht, aber sehr wohl die Suche.

Das ist ein Widerspruch.

Das Problem ist, dass du immer noch keinen eigenen Code gezeigt hast.

Du kannst es auch ohne Code verstehen. Davon bin ich felsenfest überzeugt!

Stefan124 schrieb:

Die Ordnung nicht, aber sehr wohl die Suche.

Das ist ein Widerspruch.

Er meint wohl

Danach wird mit set.find(C) gesucht.

Edit: Er meinte wohl eher das Prädikat hängt von C ab.

camper schrieb:

Stefan124 schrieb:

Die Ordnung nicht, aber sehr wohl die Suche.

Das ist ein Widerspruch.

Er meint wohl

Danach wird mit set.find(C) gesucht.

Edit: Er meinte wohl eher das Prädikat hängt von C ab.

Stefan124 schrieb:

Die statische Variable ist durch einen Mutex geschützt und wird mit b initialisiert.

Danach wird mit set.find(C) gesucht.

Der erste Satz impliziert, dass set.find(C) erst aufgerufen wird, nachdem ein lock auf dem Mutex existiert. Der Debugfehler sagt, dass die Vergleichsrelation keine strenge schwache Ordnung ist (a<b && b<a), was daran liegen kann dass entweder eines der Argumente zwischen zwei Aufrufen verändert wird (kann für C nicht sein, denn das ist geschützt; und ich nehme mal an, dass niemand an den set-Elementen herumschraubt) oder aber die Ordnungsrelation selbst defekt ist. Ohne entsprechenden Code ist dazu nicht mehr zu sagen http://www.c-plusplus.net/forum/304133

Danach wird mit set.find(C) gesucht.

Der erste Satz impliziert, dass set.find(C) erst aufgerufen wird, nachdem ein lock auf dem Mutex existiert. Der Debugfehler sagt, dass die Vergleichsrelation keine strenge schwache Ordnung ist (a<b && b<a), was daran liegen kann dass entweder eines der Argumente zwischen zwei Aufrufen verändert wird (kann für C nicht sein, denn das ist geschützt; und ich nehme mal an, dass niemand an den set-Elementen herumschraubt) oder aber die Ordnungsrelation selbst defekt ist. Ohne entsprechenden Code ist dazu nicht mehr zu sagen http://www.c-plusplus.net/forum/304133[/quote]

Eben nicht! Genau das ist ja das Problem. Der Lock schützt C nicht, weil C eine statische Variable innerhalb der Memberfunktion der Klasse ist.

Der Lock schützt zwar vor dem Zugriff von mehreren Threads auf eine Instanz der Klasse, aber eben nicht über alle Instanzen hinweg. Und genau deshalb scheitert die Suche, weil die strict weak order nicht mehr erfüllt ist, wenn während der Suche die statische Membervariable geändert wird.

BTW: Warum wird immer so ein Aufstand wegen dem Code posten gemacht. Man kann nicht immer den Code posten, weil dieser oft Bestandteil einer größeren Umgebung ist.

Warum wird immer so ein Aufstand wegen dem Code posten gemacht.

Weil du prinzipiell nur eine vermittelnde Instanz zwischen dem Code und uns bist. Die brauchen wir aber nicht, du könntest ihn uns direkt geben.

Man kann nicht immer den Code posten, weil dieser oft Bestandteil einer größeren Umgebung ist.

Dann reduzierst du den Code auf das Wesentliche. Lies den von camper verlinkten Artikel.

Eben nicht! Genau das ist ja das Problem. Der Lock schützt C nicht, weil C eine statische Variable innerhalb der Memberfunktion der Klasse ist.

Dann mache doch einfach den Mutex Instanzunabhängig!

Dann reduzierst du den Code auf das Wesentliche. Lies den von camper verlinkten Artikel.

Ich reduziere überhaupt nichts. Wer einfache deutsche Sätze nicht versteht und erst einmal 30 Zeilen bereinigten und vorgekauten Code benötigt, um triviale Sachverhalte zu verstehen, soll sich zurücklehnen und entspannen.

Niemand wird hier gezwungen zu antworten!

Arcoth schrieb:

Dann mache doch einfach den Mutex Instanzunabhängig!

Gut erkannt. Das Problem hatte ich aber schon bevor ich den Thread eröffnet hatte gelöst.

Der Lock schützt zwar vor dem Zugriff von mehreren Threads auf eine Instanz der Klasse

Aber hey, das wiederspricht sich mit

Die statische Variable ist durch einen Mutex geschützt

Statische Objekte sind nicht instanzgebunden und koennen demnach mit instanzgebundenen Synchronisationsobjekten nicht geschuetzt werden. Eine dieser Aussagen ist also falsch.

Wer einfache deutsche Sätze nicht versteht und erst einmal 30 Zeilen bereinigten und vorgekauten Code benötigt, um triviale Sachverhalte zu verstehen

Nee, du hast einfach Bockmist geschrieben. War von vornherein kalr, deswegen die Frage nach Code.

Arcoth schrieb:

Dann reduzierst du den Code auf das Wesentliche. Lies den von camper verlinkten Artikel.

Ich reduziere überhaupt nichts. Wer einfache deutsche Sätze nicht versteht und erst einmal 30 Zeilen bereinigten und vorgekauten Code benötigt, um triviale Sachverhalte zu verstehen, soll sich zurücklehnen und entspannen.

Der Grund des Verlangens nach Code ist darin begründet, dass in 99% der Fälle das Verständnis des Posters nicht zu den Vorgängen passt, die tatsächlich stattfinden. Und das ist ja durchaus normal: wäre es anders, läge die Lösung des Problemes i.d.R. auf der Hand und es gäbe keinen Grund, überhaupt hier zu posten. Das bedeutet aber eben auch, das eine verbale Beschreibung in der Regel nicht ausreicht, ein Problem zu lösen, da dann das Publikum auch nur die Fehler des Posters wiederholen kann.
All das liegt eigentlich auf der Hand, und wer keinen Code zeigen will, sollte auch keine hilfreiche Antworten erwarten. Aber wie du selbst sagst, ist dein Sachverhalt ja trivial, also klannst du dich entspannen und das Posten in diesem Forum unterlassen.

Dann geh wieder spielen. Immer diese Trollors.

Du bist der Troll!

Du weinst hier rum, weil du nicht in der Lage bist zwei deutsche Sätze zu verstehen.

Hoffentlich muss man dir an der Wursttheke im Supermarkt nicht auch erst C++-Code posten, damit du verstehst, wieviel die Mettwurst kostet und ob du sie dir leisten kannst. :p

Dann geh wieder spielen. Immer diese Trollors.

Der Lock schützt zwar vor dem Zugriff von mehreren Threads auf eine Instanz der Klasse

Aber hey, das wiederspricht sich mit

Die statische Variable ist durch einen Mutex geschützt

Statische Objekte sind nicht instanzgebunden und koennen demnach mit instanzgebundenen Synchronisationsobjekten nicht geschuetzt werden. Eine dieser Aussagen ist also falsch.

Wer einfache deutsche Sätze nicht versteht und erst einmal 30 Zeilen bereinigten und vorgekauten Code benötigt, um triviale Sachverhalte zu verstehen

Nee, du hast einfach Bockmist geschrieben. War von vornherein kalr, deswegen die Frage nach Code.

Du musst schon den kompletten Beitrag lesen. Da steht nämlich schon im ersten Beitrag explizit.

Meine Vermutung ist, dass zwar die Methode methodInA() exklusiv geschützt ist, aber dadurch das C statisch ist, über mehrere Klassen-Instanzen geteilt wird.

Und im zweiten Beitrag steht dann sogar haargenau.

dass ein Thread die statische Variable ändert.

Wenn du das nicht kapierst, dann ist dir auch nicht mehr zu helfen.

Btw. ich weiss wie statische Variablen funktionieren.

Da steht, die statische Variable ist geschuetzt.

Sie ist auch beim Zugriff von n Threads geschützt. Aber eben nicht über mehrere Instanzen hinweg!

Verstehst du das?

Man ist nicht geschuetzt, wenn man mit mehreren Sex hat und nur einer seine Socken anbehaelt. Verstehst du das?

Lol. Du bist der Forenwitzbold, stimmts?

Dein Vergleich hinkt. Die Variable kann "mit beliebig vielen Threads bumsen", solange sie nur im selben Bett bumst.