Arch Linux

[c++11] Parameter an Thread übergeben

linux-ka

Hi,

ich bin gerade bei einer Fingerübung an eine neue Hürde gestoßen, die ich allein nicht so recht zu umschiffen verstehe.
Folgendes Szenario; die Funktion

std::string  watch_mail(const std::string spool) ;

soll meine Mailordner durchgehen und bei vorhandener neuer Mail Ordner und Anzahl mittels

void check_folder(std::string spool,const std::string Folder,std::map<std::string,std::string>& Mailbox) ;

std::map<std::string,std::string> Mailbox

ablegen. Das klappt seriell wunderbar. Nun wollte ich aber einmal schauen wie das parallel funktioniert und ob man etwas spürbar an der Performance regelt.

Hierfür wird die serielle Variante:

getdir(spool,Folder);

for(std::vector<std::string>::iterator Folder_it = Folder.begin();Folder_it!=Folder.end(); Folder_it++)
{
                check_folder(spool,*Folder_it,Mailbox) ;
}

in die parallele Version umgemünzt.

std::vector<std::string>::iterator Folder_it = Folder.begin() ;
std::thread T[Folder.size()] ;

for(uint i=0; i!=Folder.size(); i++)
{
                T[i] = std::thread(check_folder,spool,*(Folder_it++),Mailbox) ;
 
}

for(unsigned int i = 0; i != Folder.size(); i++)
{
                T[i].join() ;
}

Leider bricht mir g++ mit folgenden Fehler ab, was ich nur bedingt nachvollziehen kann:

g++ mail.cpp
In file included from /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/move.h:57:0,
                 from /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_pair.h:61,
                 from /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_algobase.h:65,
                 from /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/char_traits.h:41,
                 from /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1/ios:41,
                 from /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1/ostream:40,
                 from /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1/iostream:40,
                 from ./mail.h:6,
                 from mail.cpp:1:
/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1/type_traits: In Instanziierung von »struct std::_Result_of_impl<false, false, void (*)(std::basic_string<char>, std::basic_string<char>, std::map<std::basic_string<char>, std::basic_string<char> >&), std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > >«:
/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1/type_traits:1857:12:   erfordert durch »class std::result_of<void (*(std::basic_string<char>, std::basic_string<char>, std::map<std::basic_string<char>, std::basic_string<char> >))(std::basic_string<char>, std::basic_string<char>, std::map<std::basic_string<char>, std::basic_string<char> >&)>«
/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1/functional:1563:61:   erfordert durch »struct std::_Bind_simple<void (*(std::basic_string<char>, std::basic_string<char>, std::map<std::basic_string<char>, std::basic_string<char> >))(std::basic_string<char>, std::basic_string<char>, std::map<std::basic_string<char>, std::basic_string<char> >&)>«
/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1/thread:133:9:   erfordert durch »std::thread::thread(_Callable&&, _Args&& ...) [with _Callable = void (&)(std::basic_string<char>, std::basic_string<char>, std::map<std::basic_string<char>, std::basic_string<char> >&); _Args = {const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >&}]«
mail.cpp:23:59:   von hier erfordert
/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1/type_traits:1834:9: Fehler: ungültige Initialisierung einer nicht-konstanten Referenz des Typs »std::map<std::basic_string<char>, std::basic_string<char> >&« von R-Wert des Typs »std::map<std::basic_string<char>, std::basic_string<char> >«
make: *** [mail.o] Fehler 1
Press return ...

Dass Mailbox nicht konstant ist, hat für mein Verständnis einen ersichtlichen Grund. Immerhin sollen neue Einträge in dieser map-Variable angelegt werden.

Wie ist das denn zu umschiffen, sodass ich weiterhin mit der Adresse von Mailbox arbeiten kann, um diese Variable nicht jedes Mal neu erzeugen zu müssen. Übersehe ich etwas ?

Besten Dank für eure Hilfe!

L-K

nobody44

Hallo,
Du solltest bei Multithreading übrigens beachten, dass einige Klassen nicht thread safe sind. Die std::map ist zum Beispiel eine von diesen Klassen. Das heißt, du kannst die Threads nutzen um die Ergebnisse zu berechnen, die Ergebnisse in die Map packen sollten sie allerdings nicht, denn std::map ist nicht thread safe, wenn man schreibend darauf zugreifen möchte.

Zum Fehler:
http://en.cppreference.com/w/cpp/thread/thread/thread

Versuch es mal mit std::ref(Mailbox) als Parameter.

nobody44

T.M.

Ein Problem ist meiner Ansicht nach, dass das Container-Objekt Mailbox als einfache Referenz an die Funktion übergeben und möglicherweise in beiden Richtungen benutzt wird. Das ist im Falle von single threaded legitim, bei multi threaded hingegen fatal, weil erstens zwei threads ungehindert auf diesen Container zugreifen können und zweitens das Objekt möglicherweise kürzer lebt als es benötigt wird. Dieses Objekt muss natürlich solange leben, bis der letzte (!) thread, der es benötigt, ausgelaufen ist.

Im Fall, dass keine Rückübermittling von Ergebnissen über solche Variablen nötig ist, ist es einfach: man kann alle Variablen an den thread einfach per Kopie übergeben (einfach das Referenzzeichen weg). Dann hat der thread seine eigene Kopie und kann damit anstellen, was er will. OK, es gibt einigen Aufwand zum Erzeugen der Kopie, das muss man mal analysieren, gerade wenn die Elemente des Containers recht gross sind. Ggf. muss man den Container dynamisch erzeugen und nur den Zeiger als Parameter übergeben, dann gehört der Container dem thread und muss von ihm gelöscht werden.

Anderenfalls, wenn also in dem Container auch ein Ergebnis zurückübermittelt werden muss, muss diese Variable länger leben als der thread. Üblicherweise erzeugt man solche Objekte, die also Daten zwischen threads austauschen, dynamisch, also mit new, und packt sie in einen smart pointer mit Referenzzählung, also einen shared_ptr<>, der dafür sorgt, dass das Löschen genau im richtigen Moment erfolgt, aber eben nicht zu früh. Man übergibt dann eine Kopie dieses shared_ptr<> als Parameter an den thread. Ausserdem muss dann ein Mechanismus da sein, der den aufrufenden thread davon benachrichtigt, dass das Ergebnis jetzt in dem Container verfügbar ist und vom aufgerufenen thread nicht mehr verändert wird. Ersterer muss nicht darauf warten, er kann schon in der Zwischenzeit andere Dinge tun, aber es muss klar gewährleistet sein, dass nicht beide threads gleichzeitig auf dem Container operieren. Das nennt man thread-Synchronisation, in bestimmten Augenblicken (speziell bei der Datenübergabe am Ende) müssen threads synchronisiert werden. Dafür benutzt man Mutexe und spezielle locking-Klassen. Das Abfragen einer einfachen bool-Variable "ready" o.ä. oder von size() oder empty() auf dem Container innerhalb einer Warteschleife o.ä. sind dafür ungeeignet (eben nicht thread-safe).

(Multithreading ist wie mehrere Autos zugleich fahren ...)

linux-ka

Danke für das Feedback, bin gerade nicht am Heimrechner und werde daher das std::ref() später testen.

Die map-Variable Mailbox existiert die ganze Zeit und wird auch nach Ablauf der Threads weiter verwendet. Somit muss man keine Angst bezüglich der Lebenszeit während der Threads hegen. Ich weiß nicht ob mutex in diesem Fall etwas oversized ist...kan man den shared_pointer auch oihne mutex verwenden ? Muss mich da mal genauer einlesen.

T.M.

linux-ka schriebDie map-Variable Mailbox existiert die ganze Zeit und wird auch nach Ablauf der Threads weiter verwendet. Somit muss man keine Angst bezüglich der Lebenszeit während der Threads hegen.

Ja, bis hierhin ok.

Ich weiß nicht ob mutex in diesem Fall etwas oversized ist...kan man den shared_pointer auch oihne mutex verwenden ? Muss mich da mal genauer einlesen.

Das Problem ist, dass im aufrufenden thread unklar ist, wann der aufgerufene thread die Daten fertig hat, so dass sie ab nun im aufrufenden thread als Ergebnis weiterverwendet werden können. Wie gesagt, es genügt nicht, aus dem aufgerufenen thread heraus eine einfache bool-Variable o.ä. zu setzen, auf die der aufrufende thread dann wartet, das ist nicht threadsicher, auch wenn's zufällig vielleicht ein paarmal gelingt. Du darfst in einem thread keine einzige Variable auch nur lesen, die ein anderer thread möglicherweise beschreibt, weil Du nicht vorhersagen kannst, wann das konkret passieren und ob es dem Lesevorgang in die Quere kommen wird. Für diese Synchronisation brauchst Du ein spezielles, ausdrücklich threadsicheres Objekt, wofür in allen threading-Bibliotheken spezielle Klassen oder Funktionen existieren. Und so ein Mutex ist ja nichts weiter als genau so ein threadsicheres bool. - Ist einfacher als man denkt. Man schreckt zunächst vor dem Aufwand zurück, aber es funktioniert üblicherweise recht einfach und zuverlässig.

linux-ka

Danke für die ermutigenden Worte :-) ich werd mich dann mal an mutex heranpirschen....wenn ich dann aber die map-Variable für den einen Thread zum Lesen sperre wenn der andere schreibt, oder auch umgekehrt, läuft dann der ganze Prozess letztenendes nicht wieder seriell ab...thread 1 warted auf thread 2 damit dieser mit schreiben fertig ist, usw...oder läuft dann nur das Editieren der Variable seriell ab, aber der Rest parallel ? Im Grunde schreibt jeder Thread am Ende seiner Laufzeit etwas in Mailbox rein, falls eine neue Mail da ist, oder eben auch nicht....

nobody44

Hi,
Wenn du nicht mit Mutex arbeiten willst, kannst du jeden Thread das Ergebnis bestimmen lassen. Du musst dann die Ergebnisse im Hauptthread der map hinzufügen...
Wie schreibst du in die Map in der Funktion check_folder?

Als Beispiel:

#include <thread>
#include <iostream>

#define THREADS 20

using namespace std;

void test_function(const unsigned int zahl, unsigned int& target) {
    target = zahl;
}


int main() {
    unsigned int zahlen[THREADS];
    std::thread threads[THREADS];

    for(unsigned int i = 0; i < THREADS; ++i) {
        threads[i] = std::thread(test_function, i, std::ref(zahlen[i]));
    }

    for(unsigned int i = 0; i < THREADS; ++i) {
        threads[i].join();
    }

    for(unsigned int i = 0; i < THREADS; ++i) {
        cout << "Zahl " << i << ": " << zahlen[i] << endl;
    }
}

Ich lasse die Threads "das Ergebnis" berechnen, diese schreiben es direkt in ein Array (das ist thread safe), und anschließend kann ich die Ergebnisse in einen beliebigen Container packen (dieser muss nicht zwingend thread safe sein).
Das könnte man jetzt an deinen Code anpassen...

nobody44

Schulteatq

Wenn es um mehr als Threadprogrammierung lernen geht, empfehle ich Intel TBB als Threading Library. Bringt concurrent containers, mutexe, threads, jobs, etc. direkt mit, wird breit unterstützt und hat ein sehr schönes Interface.

T.M.

nobody44 schriebWenn du nicht mit Mutex arbeiten willst, kannst du jeden Thread das Ergebnis bestimmen lassen. Du musst dann die Ergebnisse im Hauptthread der map hinzufügen...
    for(unsigned int i = 0; i < THREADS; ++i) {
        threads[i].join();
    }

Die join-Methode macht nichts weiter, als den Hauptthread solange anzuhalten, bis die einzelnen sub-threads beim Auslaufen ein jeweils internes Mutex freigeben.

T.M.

Schulteatq schriebWenn es um mehr als Threadprogrammierung lernen geht, empfehle ich Intel TBB als Threading Library. Bringt concurrent containers, mutexe, threads, jobs, etc. direkt mit, wird breit unterstützt und hat ein sehr schönes Interface.

pthreads, auch anfänglich unter C++. Das ist hinreichend einfach. Wenn man mal ein Programm mit pthreads zum Laufern gebracht hat, versteht man auch threading-Implementierungen auf anderen Plattformen, inkl. Windows. Für saubere, portable C++-Entwicklung würde ich boost-threads empfehlen.

Ich halte es für klug, ein Thema wie multithreading mit einer einfachen, minimalen Bibliothek zu beginnen, weil dann automatisch nach und nach die Probleme sichtbar werden und man diese intuitiv versteht. Wenn man hingegen gleich auf ein umfangreiches Framework setzt und dessen Funktionalität einfach benutzt, weil sie halt da ist, versteht man oft nicht viel davon. Es geht einfach irgendwie, und man sucht später lange nach Laufzeit- und Ressourcenkillern o.ä.

nobody44

T.M. schrieb
nobody44 schriebWenn du nicht mit Mutex arbeiten willst, kannst du jeden Thread das Ergebnis bestimmen lassen. Du musst dann die Ergebnisse im Hauptthread der map hinzufügen...
    for(unsigned int i = 0; i < THREADS; ++i) {
        threads[i].join();
    }
Die join-Methode macht nichts weiter, als den Hauptthread solange anzuhalten, bis die einzelnen sub-threads beim Auslaufen ein jeweils internes Mutex freigeben.

Das ist korrekt. Es macht IMHO aber einen Unterschied, ob ich direkt mit Mutexen arbeite, oder ob das die Bibliothek im Hintergrund für mich erledigt.

Ich finde den neuen Standard übrigens sehr praktisch... so viele tolle Neuerungen 🙂...

Funktioniert std::thread auch unter Windows so schön?

Schulteatq

T.M. schriebIch halte es für klug, ein Thema wie multithreading mit einer einfachen, minimalen Bibliothek zu beginnen, weil dann automatisch nach und nach die Probleme sichtbar werden und man diese intuitiv versteht. Wenn man hingegen gleich auf ein umfangreiches Framework setzt und dessen Funktionalität einfach benutzt, weil sie halt da ist, versteht man oft nicht viel davon. Es geht einfach irgendwie, und man sucht später lange nach Laufzeit- und Ressourcenkillern o.ä.

Wenn es nur ums Lernen geht, dann auf jeden Fall. Daher auch mein einleitender Nebensatz in obigem Post. Wenn man aber produktiv multi-threaded C++ programmieren möchte/muss/darf, dann ist TBB eine großartige Sache und kein Vergleich zu pthreads.

Funktioniert std::thread auch unter Windows so schön?

Klar, Windows kennt auch Threads. Alles was Du brauchst ist ein C++11 Compiler - leider siehts bei MSVC 2010 noch sehr dunkel mit c++11 aus (insbesondere kein std::thread). Evtl. hat MSVC 2012 ne pasende Implementierung an Bord.

nobody44

Dass Windows Threads kennt ist mir bekannt 😉. Naja... ist mir letztendlich auch egal, programmiere nichts für Windows.

T.M.

Schulteatq schriebKlar, Windows kennt auch Threads. Alles was Du brauchst ist ein C++11 Compiler - leider siehts bei MSVC 2010 noch sehr dunkel mit c++11 aus (insbesondere kein std::thread). Evtl. hat MSVC 2012 ne pasende Implementierung an Bord.

std::threads sind doch auch im wesentlichen boost::threads, oder? Vieles, was jetzt nach std gewandert ist (auch shared_ptr<> usw.), stammt doch aus boost, zumindest konzeptionell. Vielleicht ist die Implementierung etwas abgerüstet, weil diese dann bei einem konkreten Compiler nicht mehr so viele Plattformen unterstützen muss wie eine universelle Bibliothek. Wenn man also heute noch keinen echten C++11-Compiler vorliegen hat, so kann man dennoch ein Programm schreiben, das sich schnell in ein solches umwandeln lässt. Wahrscheinlich genügt es, später die header und namespaces zu tauschen.

linux-ka

Hi,

ich hatte Zeit mich wieder an den Quelltext zu setzen:

Folgendes habe ich versucht:

for(uint i=0; i!=Folder.size(); i++)
        {
                T[i] = std::thread(check_folder,spool,*Folder_it,std::ref(Mailbox)) ;
                Folder_it++ ;
        }

sowie

void check_folder(std::string spool,const std::string Folder,std::map<std::string,std::string>& Mailbox)
{
        int mails_new = -2 ;

        spool = spool + "/" + Folder + "/new" ;

        DIR *dp;
        struct dirent *dirp;

        if((dp  = opendir(spool.c_str())) == NULL)
        {
               // std::cerr << "Error(" << errno << ") opening " << spool << std::endl;
                return ;
        }

        while ((dirp = readdir(dp)) != NULL)
        {
                mails_new++ ;
        }
        closedir(dp);

        if( mails_new )
        {
                std::stringstream ss ;
                ss << mails_new ;

                mutex.lock() ;
                Mailbox[Folder] = ss.str() ;
                mutex.unlock();
        }
}

Alles kompiliert soweit gut, aber beim Linken passiert am Ende folgendes:

main.o: In function `operator<< <std::char_traits<char> >':
/usr/lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../include/c++/4.7.2/ostream:528: multiple definition of `mutex'
mail.o:/usr/lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../include/c++/4.7.2/ext/atomicity.h:77: first defined here
collect2: Fehler: ld gab 1 als Ende-Status zurück

mutex habe ich in der header datei definiert:

#ifndef _mutex
#define _mutex 
#include <mutex>
std::mutex mutex ;
#endif

Damit sollte mutex doch nur einmal definiert sein....

linux-ka

Ah, Problem gefunden....ich darf

std::mutex mutex

nicht im header definieren....wenn ich es in mail.cpp reinpacke ist alles heile.....

Im Grunde geht es so recht einfach mehrere threads zu nutzen. Der Nutzen ist zwar in diesem Beispiel minimal bis gar nicht vorhanden, aber der Lerneffekt ist nicht zu verachten. Und auch wenn man die mutexe weiter aufbohren kann, langt dieser minimale Eingriff scheinbar, damit nichts schief läuft.

Kann ich den auf diese Weise auch zwei threads unterschiedlicher Art laufen lassen und über Variablen kommunizieren lassen?

Sprich, kann das dann wieder mit adressen und std::ref(foo) erledigt werden ?

T.M.

linux-ka schriebAh, Problem gefunden....ich darf
std::mutex mutex 
nicht im header definieren....wenn ich es in mail.cpp reinpacke ist alles heile.....

Logisch. Jedes include erzeugt hier am Ort des includes eine neue Instanz dieser Variable, was beim Compilieren nicht auffällt, beim Linken aber zu mehreren gleichnamigen, globalen Objekten führt. Wichtig ist, dass alle threads, die Du synchronisieren willst, mit dem gleichen Mutex arbeiten. Es darf dann also nicht in jeder cpp-Datei ein neues erzeugt werden. Dieses Mutex muss übrigens nicht zwingend global sein. Du kannst es auch im Hauptthread (also z.B. in der main-Funktion) erzeugen und per Referenz an die Sub-threads übergeben.

Im Grunde geht es so recht einfach mehrere threads zu nutzen. Der Nutzen ist zwar in diesem Beispiel minimal bis gar nicht vorhanden, aber der Lerneffekt ist nicht zu verachten.

Gut, dass dieser Effekt hervortritt. Man muss das begreifen, sonst werden viele Dinge nicht klar, die später irgendwann unweigerlich auftreten, vor allem unerklärliche Zeitverluste oder gar Stillstehen (weil nämlich threads aufeinander warten müssen) u.ä.

Kann ich den auf diese Weise auch zwei threads unterschiedlicher Art laufen lassen und über Variablen kommunizieren lassen?

Sprich, kann das dann wieder mit adressen und std::ref(foo) erledigt werden ?

Denk schon. Bisschen Konzept gehört schon dazu, aber man kann es beliebig komplex machen.

Eine wichtige Sache in dem Zusammenhang sind noch read- und write-Locker, also Klassen, die Mutexe im Konstruktor locken und im Destruktor wieder freigeben. Der Vorteil ist, dass man das Freigeben nicht vergessen oder überspringen kann, es passiert garantiert, selbst noch im Falle von exceptions, die ja immer unterwegs auftreten können. Zwotens kann man mit diesen Klassen Lese- und Schreibzugriffe verbessert koordinieren: das Lesen ist ja nicht kritisch, lesen können mehrere threads gleichzeitig eine Variable, nur das Schreiben darauf muss in dem Moment verhindert werden. Schreiben allerdings dürfen niemals mehrere auf ein- und dieselbe Variable, das muss man klar ausschliessen. Die Stichworte hier lauten (bei boost (und std ?)) shared_lock<> und upgrade_lock<>. Beide Klassen verlangen ein Mutex als Parameter. Vorsicht ist bei Verwendung dieser Klassen geboten, um den Wirkungsbereich (also das Locken) so kurz wie möglich zu halten, d.h. man muss Klammern speziell für diesen Zweck einfügen:

shared_mutex m;
int global_i;
...
void my_thread_proc ()
{
    int local_i = 0;

    ...

    // Lesen einer globalen Variable in einem thread, nur shared_lock<> nötig, dieses verbietet allerdings Schreibvorgänge in anderen threads
    {
        shared_lock<shared_mutex> read_lock(m);
        local_i = global_i;
    } // <- diese Klammer beendet das read_lock

    ...

    // Schreiben einer globalen Variable in einem thread, upgrade_lock nötig, dieses verbietet Lese- und Schreibvorgänge in anderen threads
    {
        upgrade_lock<shared_mutex> upgrade(m);
        upgrade_to_unique_lock<shared_mutex> write_lock(upgrade);
        global_i = local_i;
    } // <- diese Klammer beendet das write_lock
    ...
}

Wichtig ist, dass man alle Lese- und Schreibvorgänge als solche erkennt und immer so lockt. Dann kann eigentlich fast nichts mehr schiefgehen.

linux-ka

Ok, das ist schon eine Stufe weiter :-) Im Grunde ist das was du beispielhaft hervorgehoben hast eine aufgebohrte Version des einfachen mutex.lock()/mutex.unlock() oder entegehen mir gerade die feinen Nuancen ?
Ab wann wird denn diese Klassennutzen obligatorisch ?

T.M.

linux-ka schriebOk, das ist schon eine Stufe weiter :-) Im Grunde ist das was du beispielhaft hervorgehoben hast eine aufgebohrte Version des einfachen mutex.lock()/mutex.unlock() oder entegehen mir gerade die feinen Nuancen ?

Naja, die Nuance besteht darin, dass ich read- und write-locks unterscheide. Du lockst ja generell, das entspricht also einem write-lock, auch für Lesezugriffe. Es funktioniert sicher, sperrt aber threads auch dann, wenn diese nur lesen wollen. Das kann in grossen Applikationen dazu führen, dass threads länger und öfter als nötig aufeinander warten.

Ab wann wird denn diese Klassennutzen obligatorisch ?

Ist nicht obligatorisch, nur eleganter und weit sicherer. Stell Dir eine grössere Menge Code drumherum vor mit einem Haufen ifs und Schleifen und vielleicht noch #ifdefs und sowas. Dann siehst Du möglicherweise nicht mehr gleich, wo das unlock steht und ob und wann es wirklich durchlaufen wird. Ein echtes Problem sind exceptions, weil diese ein unlock knallhart verhindern können: Wenn Du ein Mutex gelockt hast und dann aus irgendeinem Grunde eine exception auftritt, bleibt das Mutex gelockt. Das führt sehr schnell zu stehenden threads und allokierten Ressourcen, wobei das Zumstehenkommen üblicherweise andere (!) threads betrifft. In der Tat sind (aus welchem Grunde auch immer) unpaarweise ausgeführte locks und unlocks ein sehr häufiger und schwer zu behebender Fehler, vielleicht der häufigste Fehler im Multithreading überhaupt. Diese Klassen bilden da eine ebenso einfache wie wirkungsvolle Abhilfe. Es ist (bis auf ganz wenige, seltene Fälle) von Vorteil, die lock- und unlock-Funktionen (oder Methoden) auf einem Mutex nicht von Hand aufzurufen.

linux-ka

Dann werd ich das bei Gelegenheit mal versuchen umzumünzen :-) danke !

Nächste Seite »

Datenschutz
Impressum