boost::mutex explizit locken und unlocken
-
Hi,
kann ich einen boost::mutex auch explizit locken, unlocken und trylocken? Also ohne scoped_lock wie beim pthread_mutex?
thx im Voraus
-
Nein. Das ist absichtlich so: http://boost.org/doc/html/thread/rationale.html#thread.rationale.locks
-
Und eine IMO richtig dumme Entscheidung.
-
Die ganze Boost::Threads Bibliothek ist eher suboptimal. Man kann ja noch nicht mal Threads canceln.
-
Eine IMO richtig gute Entscheidung.
-
Tyrdal schrieb:
Man kann ja noch nicht mal Threads canceln.
wenn man threads von aussen killt, handelt man sich oft probleme ein. deshalb bieten viele libs das auch gar nicht erst an. setz einfach ein flag, das der thread periodisch abfragt, damit er sich selbst beenden kann.
-
Ich finde die boost::threads eigentlich ganz gut. Mit Hilfe von boost::bind kann man sogar nicht-statische Memberfunktionen verwenden.
Aber wer boost::threads nicht mag hat ja genug Alternativen:
http://openthreads.sourceforge.net/
http://zthread.sourceforge.net/
http://sourceware.org/pthreads-win32/
-
Das war keine Entscheidung vom Autor. Er führt das in der Doku auch als Mangel an.
Und bei dem Problem wo es damals relevant gewesen wäre, hätte das mit Flag auch nicht geholfen. Ist aber egal, da nicht mehr aktuell.
-
scoped_lock kann man nicht bei rekursiven Funktionen verwenden, daher ist das ein echter Designfehler.
-
Für den Fall gibt es recursive_mutex: http://www.boost.org/doc/html/boost/recursive_mutex.html
-
Tyrdal schrieb:
Das war keine Entscheidung vom Autor. Er führt das in der Doku auch als Mangel an.
Threads extern canceln zu können wird generell als schlecht betrachtet. Java hat zB thread.stop() deshalb sogar nachträglich gestrichen weil es mehr probleme als nutzen bringt.
-
K. K. schrieb:
scoped_lock kann man nicht bei rekursiven Funktionen verwenden, daher ist das ein echter Designfehler.
kein problem, man macht einfach 2 versionen jeder funktion, eine lockende und eine "no lock" version.
die lockende version lockt und ruft dann die "no_lock" version auf.
die "no_lock" version darf sich dann gerne selbst aufrufen.die ganzen "no_lock" versionen kann man auch private bzw. protected machen, wenn man den client vor sich selbst schützen möchte.
oder eben man verwendet recursive_mutex, dann hat man das problem gleich garnicht.
natürlich ist eine recursive_mutex je nach plattform um ein stück langsamer als eine normale, aber so wahnsinnig schlimm ist es dann auch nicht.
-
hustbaer schrieb:
kein problem, man macht einfach 2 versionen jeder funktion, eine lockende und eine "no lock" version.
Ich wuerde eher sagen, man schreibt eine proxy funktion die den lock macht und dann die echte funktion aufruft. diese kann sich dann austoben wie sie lustig ist.
das hast du vermutlich eh gemeint - wollte das nur kurz klarstellen.
