STL Container & Threads

[Gast]

Hi,

man liest sehr unterschiedliche Dinge wie Thread-safe die STL Container und auch verschiedene STL Implementationen sind. Gibt es da einen kleinsten gemeinsamen Nenner? Wenn ich auf eine std::queue<int> zugreife, muß ich wahrscheinlich bei queue.push(i) andere ausschließen, oder? Muß ich das auch, wenn ich ein queue.front() & queue.pop() mache und selbst bei einem if (!queue.empty())?

[Gast]

Würde sagen der kleinste gemeinsame Nenner ist es ist im Zweifel nichts thread safe ist, außer rein lesende Zugriffe oder Zugriffe die sich auf verschiedene Container beziehen.

[Ectoplasma]

Die STL ist nicht Thread safe, auch nicht lesend. Und es wäre auch schlecht, wenn sie es wäre. Ein Grund ist der Overhead für Thread-Sicherheit und ein anderer die fehlende Standardisierung für Threads und Thread-Synchronisation.

Wenn man die STL Thread safe machen will, dann muss man eine Wrapper-Klasse für einen STL-Container erstellen, die das erledigt.

[Gast]

Gibt es denn eine gute Alternative zur STL in Form einer thread-sicheren queue?

Ich suche nach einer Möglichkeit von hinten jederzeit Elemente anzufügen und aus einem anderen Thread vorne wegzunehmen, und dabei den Synchronisationsoverhead auf ein Minimum zu reduzieren.

Ich könnte mir vorstellen, daß es interne Möglichkeiten für eine Solche Queue gibt die Notwendigkeit von gegenseitigem Ausschluß in einigen Fällen zu reduzieren. Oder wäre eine solche Queue auch nicht effizienter als einfach vor jeder Operation die Queue komplett zu sperren?

danke

[rotalever]

Gibt es denn eine gute Alternative zur STL in Form einer thread-sicheren queue?

In boost müsste es sowas doch eigentlich geben.

[Bietchiebatchie]

Gibt es denn eine gute Alternative zur STL in Form einer thread-sicheren queue?

Ich suche nach einer Möglichkeit von hinten jederzeit Elemente anzufügen und aus einem anderen Thread vorne wegzunehmen, und dabei den Synchronisationsoverhead auf ein Minimum zu reduzieren.

Ich könnte mir vorstellen, daß es interne Möglichkeiten für eine Solche Queue gibt die Notwendigkeit von gegenseitigem Ausschluß in einigen Fällen zu reduzieren. Oder wäre eine solche Queue auch nicht effizienter als einfach vor jeder Operation die Queue komplett zu sperren?

danke
Mag sein, dass es eine synchronisierte Queue in Boost gibt, allerdings könnte sie wenn überhaupt den Overhead nur gering beeinflussen.
Wenn der Overhead bei dir zu groß ist würde ich lieber z.B. bis zu x Objekte in dem einen Thread nochmal extra queuen und wenn die Anzahl der Objekte x überschreitet alle in einem Rutsch in die andere Queue schreiben.


Ansonsten
[x] Absolut dagegen, Objekte vorsorglich zu synchronisieren (außer bei solchen bei denen Nicht-synchronisieren widersinnig wäre - Threads, Mutex etc.)

[ethrandil]

Ja - vorsorglich threadsafe machen ist oft quatsch. Wieso? Man versucht sich die Arbeit abzunehmen exakt zu analysieren, wo man konkurrierende Zugriffe braucht. Wenn man das aber lässt, dann ergibt sich äufig ein schwer zu debuggendes Kudelmuddel.
Also: Algorithmen analysieren & dann zielgerichtet absichern.

Wenn aber die Queue das einzige ist was die Schnittstelle zwischen den Threads darstellt - dann kann man da ruhig ne threadsafe variante nehmen ^^

mfg
- eth

[Gast]

Wenn der Overhead bei dir zu groß ist würde ich lieber z.B. bis zu x Objekte in dem einen Thread nochmal extra queuen und wenn die Anzahl der Objekte x überschreitet alle in einem Rutsch in die andere Queue schreiben. Könnte sowas eine synchronisierte Queue eigentlich nicht auch intern machen?

[Bietchiebatchie]

Könnte sowas eine synchronisierte Queue eigentlich nicht auch intern machen?
Du meinst, dass die Queue intern eine eigene Queue verwaltet? Das macht nicht wirklich Sinn.