std::thread oder pthread
-
Guten Morgen.
Ist es Sinnvoll, wenn man bei bestehenden/neuen Diensten statt pthread std::thread verwendet?
Es ist so, dass ich eine Art Threadüberwachung machen möchte und da könnte ich eben diese Umstellung gleich mitmachen, außer ich verliere mit so einer Umstellung wichtige Infos?
DANKE für Eure Hilfe.
Johannes
-
Ja.
wichtige Infos
Das waeren?
-
Du kriegst die wichtige PThread-Info leicht aus std::thread raus: http://en.cppreference.com/w/cpp/thread/thread/native_handle
-
knivil schrieb:
Ja.
Kannst du mir ev. noch sagen, warum es sinnvoll wäre so eine Umstellung zu machen?
knivil schrieb:
wichtige Infos
Das waeren?
Hehe, ja das weiß ich noch nicht, ich wollte nur damit verhindern/aussagen, dass ich wegen irgendwelchen unbedachten Infos nicht alles wieder zurückbauen möchte.
imfo schrieb:
Du kriegst die wichtige PThread-Info leicht aus std::thread raus: http://en.cppreference.com/w/cpp/thread/thread/native_handle
ah super! Danke!
-
taff schrieb:
knivil schrieb:
Ja.
Kannst du mir ev. noch sagen, warum es sinnvoll wäre so eine Umstellung zu machen?
Weil die Schnittstelle der C++-Threads viel besser zu C++ passt*. Außerdem wird der Code dadurch unabhängig von der unterliegenden Thread-Bibliothek. Zudem sind viele Standardaufgaben für die Synchronisation bereits in der Standardbibliothek gelöst, so dass man das nicht mehr alles selber programmieren braucht.
Wenn du für dein Projekt bereits selber eine schöne Schnittstelle um die PThreads geschrieben hast (oder beispielsweise Boost-Threads benutzt, die das Vorbild für die C++-Threads sind), dann ist eine Umstellung nicht wirklich nötig.
*: Das heißt nicht nur Unterstützung komplexer Datentypen und beliebiger Parameterlisten, sondern vor allem Typsicherheit und wie mit Ressourcen umgegangen wird.
-
SeppJ schrieb:
Wenn du für dein Projekt bereits selber eine schöne Schnittstelle um die PThreads geschrieben hast (oder beispielsweise Boost-Threads benutzt, die das Vorbild für die C++-Threads sind), dann ist eine Umstellung nicht wirklich nötig.
Genau so eine eigene Thread-Klasse ist schon schon vorhanden
SeppJ schrieb:
*: Das heißt nicht nur Unterstützung komplexer Datentypen und beliebiger Parameterlisten, sondern vor allem Typsicherheit und wie mit Ressourcen umgegangen wird.
Könnte es auch bedeuten, dass etwas besser skaliert oder Compiler Optimierungen (GCC) somit besser gereifen?
Oder wäre es sowieso das beste, wenn man nicht auf std::thread umstellt, sondern auf boost::thread (weil angeblich die noch mehr können, besser sind, etc. (obwohl std::thread von boost::thread abgeleitet ist))?!
Interessieren würde mich auch noch ob es Probleme gibt, wenn man std::threads verwendet und pthread_mutex? Oder muss man da sogar auf eine gewisse "Reinheit" achten, weil es sonst zu Problemen kommen kann/wird?
-
taff schrieb:
Könnte es auch bedeuten, dass etwas besser skaliert oder Compiler Optimierungen (GCC) somit besser gereifen?
Gegenüber einer eigenen Threadklasse? Unwahrscheinlich. Es sei denn, du hast immer noch Funktionen, die du über void* mit Argumenten fütterst, was ineffizient sein kann. Aber ich nehme mal an, das hast gerade nicht mehr, oder?
Oder wäre es sowieso das beste, wenn man nicht auf std::thread umstellt, sondern auf boost::thread (weil angeblich die noch mehr können, besser sind, etc. (obwohl std::thread von boost::thread abgeleitet ist))?!
Ich hätte jetzt eher gesagt, dass std::thread mächtiger ist (bessere Unterstützung asynchroner Aufgaben). An sich sollten die sich aber nicht viel tun. Theoretisch kann std::thread besser an die unterliegende Plattform angepasst sein, aber ich denke nicht, dass da viel zu holen ist.
Bleibt Portabilität:
Pro-Boost: Auch verfügbar, wo kein C++11 verfügbar ist.
Pro-C++11: Man braucht kein Boost
Fazit: Man nehme das, was eher auf allen Zielplattformen vorhanden ist. Ist beides gleich, nehme man C++11=Threads.Interessieren würde mich auch noch ob es Probleme gibt, wenn man std::threads verwendet und pthread_mutex? Oder muss man da sogar auf eine gewisse "Reinheit" achten, weil es sonst zu Problemen kommen kann/wird?
Das sollte funktionieren, wenn die unterliegende Plattform PThreads benutzt. Aber wieso sollte man das tun wollen? Das hätte doch nur Nachteile gegenüber dem boost::mutex oder dem std::mutex, die beide nichts anderes sind als RAII-Wrapper um einen pthread_mutex (wenn die Plattform pthreads benutzt). Eine Exception im Code und dein pthread_mutex explodiert. Ebenso, wenn du die Freigabe vergisst. Mit den Wrappern kann gar nichts passieren.
-
taff schrieb:
Kannst du mir ev. noch sagen, warum es sinnvoll wäre so eine Umstellung zu machen?
Weils in der Standardbibliothek ist.
PS: Langfristig betrachtet ist Verfuegbarkeit von C++11 kein Argument.
-
SeppJ schrieb:
Aber ich nehme mal an, das hast gerade nicht mehr, oder?
Ja das sollte bereinigt sein.
SeppJ schrieb:
Ich hätte jetzt eher gesagt, dass std::thread mächtiger ist (bessere Unterstützung asynchroner Aufgaben).
in wie weit das laut dem Inhalt des links gültig ist kann ich nicht sagen bzw. kann ich die unterschiede auch nicht beurteilen.
http://stackoverflow.com/questions/7241993/is-it-smart-to-replace-boostthread-and-boostmutex-with-c11-equivalentsSeppJ schrieb:
Bleibt Portabilität:
Pro-Boost: Auch verfügbar, wo kein C++11 verfügbar ist.
Pro-C++11: Man braucht kein Boost
Fazit: Man nehme das, was eher auf allen Zielplattformen vorhanden ist. Ist beides gleich, nehme man C++11=Threads.Meine Überlegung ist ua. auch, dass ich zuerst auf boost::thread umstelle und bei Bedarf auf std::thread, weil ich das mit unserem compile-system am schnellsten lösen könnte, jedoch ist mir der Aufwand eines nochmaligen switches noch nicht ganz bewusst.
Das sollte funktionieren, wenn die unterliegende Plattform PThreads benutzt. Aber wieso sollte man das tun wollen? Das hätte doch nur Nachteile gegenüber dem boost::mutex oder dem std::mutex, die beide nichts anderes sind als RAII-Wrapper um einen pthread_mutex (wenn die Plattform pthreads benutzt). Eine Exception im Code und dein pthread_mutex explodiert. Ebenso, wenn du die Freigabe vergisst. Mit den Wrappern kann gar nichts passieren.
Es ist so, dass wir eine eigene lock-klasse haben die auch selbstständig ein unlock macht. Mein Hintergedanke dabei ist folgender: Es gibt leider ältere Services die noch nicht die selbstgebaute Thread-Klasse verwenden und somit würde eine Vermischung zustande kommen.
-
Zur Zeit ist std::thread noch nicht in allen Compilern vollständig implementiert.
Ich benutze deswegen noch boost::thread, werde es aber in Zukunft umstellen.
-
taff schrieb:
Es ist so, dass wir eine eigene lock-klasse haben die auch selbstständig ein unlock macht. Mein Hintergedanke dabei ist folgender: Es gibt leider ältere Services die noch nicht die selbstgebaute Thread-Klasse verwenden und somit würde eine Vermischung zustande kommen.
Dann ist es doch das gleiche wie die Mutexe in Boost und C++11. Hinter beidem steht schließlich bloß irgendein atomic.
Insgesamt scheinst du Boost bzw. C++11 bereits selbstständig nachprogrammiert zu haben. Insofern ist ein Wechsel eigentlich nur Geschmackssache.
taff schrieb:
in wie weit das laut dem Inhalt des links gültig ist kann ich nicht sagen bzw. kann ich die unterschiede auch nicht beurteilen.
http://stackoverflow.com/questions/7241993/is-it-smart-to-replace-boostthread-and-boostmutex-with-c11-equivalentsTolle Liste
. Ich würde da nicht wirklich von nennenswerten Vor- oder Nachteilen reden, eher von Unterschieden.
-
SeppJ schrieb:
Insgesamt scheinst du Boost bzw. C++11 bereits selbstständig nachprogrammiert zu haben. Insofern ist ein Wechsel eigentlich nur Geschmackssache.
danke für die infos.
