Erklärung für Klassen in thread.h gesucht ...

Ich versuchs mal:

Zunächst die Klassen an sich...

cMutex ist ein Mutual Exclusion Device. Er wird benutzt, um auszuschliessen, dass zwei Thread gleichzeitig etwa kritische Codestellen durchlaufen. Dazu kann ein cMutex gesperrt und entsperrt werden. Während ein Mutex gesperrt ist kann er keinesfalls nochmal gesperrt werden. Versucht ein zweiter Thread dies, muss er warten, bis der erste Thread die Sperre aufgehoben hat.

cMutex my_mutex;
void Thread1(void) {
    my_mutex.Lock();
    schreibe_in_queue();
    my_mutex.Unlock();
}
void Thread2(void) {
    my_mutex.Lock(); // <- Wartet, bis Thread 1 den Unlock()-Aufruf abgeschlossen hat
    lese_und_loesche_aus_queue();
    my_mutex.Unlock();
}

cRwLock verhält sich im Prinzip ganz ähnlich, nur wird er verwendet, um geteilten und exclusiven Zugriff zu ermöglichen. Ein cRwLock kennt zwei Sperren: Eine Schreibsperre und eine Lesesperre. Während eine Schreibsperre aktiv ist, kann kein anderer Thread den cRwLock sperren (weder lesend noch schreibend). Ist jedoch nur eine Lesesperre verhängt, kann ein anderer Thread diesen cRwLock auch lesend, jedoch nicht schreibend sperren.

Benutzen kann man das, wenn man eine Liste hat aus der beliebig oft (parallel) gelesen werden darf, in die jedoch nur geschrieben werden darf wenn _kein_ Lesevorgang mehr aktiv ist.

Eine cCondVar ist eine sogenannte wartente Kondition. Ein Thread kann sie schlafen schicken, währenddessen ein anderer sie wieder wecken kann. Damit nun sichergestellt werden kann, dass ein Thread wirklich wartet, wenn ein anderer ihn wecken will, muss eine cCondVar im Zusammenspiel mit einem cMutex verwendet werden. Während die cCondVar nun wartet, entsperrt sie den (zuvor manuell gesperrten) Mutex. Dann weiss der weckende Thread (dadurch dass er die Sperre erhält), dass der andere Thread wirklich wartet. Der wartende Thread sperrt nach dem Wecken nun den Mutex wieder und wartet somit dass der weckende Thread die Sperre aufhebt.

cMutex my_mutex;
cCondVar my_condvar;
cList my_list;
void Thread1(void) {
    my_mutex.Lock();
    while (active) {
        do_something_with_list();


        my_condvar.Wait(&my_mutex); // <- my_mutex wird entsperrt und Thread geht schlafen
        // <- nach dem Wecken wird my_mutex wieder gesperrt, bevor Wait die Kontrolle zurückgibt!!!
    }
    my_mutex.Unlock();
}


void Thread2(void) {
    while (active) {
        do_something_not_related_to_thread1();


        my_mutex.Lock(); // <- da der Mutex in Thread1 gesperrt wird wartet dieser Befehl bis Thread 1 schläft
        do_something_with_list();
        my_condvar.Broadcast(); // <- Thread wecken
        my_mutex.Unlock(); // <- erst wenn Thread2 _diese_ Zeile bearbeitet hat, bekommt Thread1 den mutex zurück und Wait gibt die Kontrolle zurück
    }
}

cCondWait ist eine Kapselung aus cCondVar und cMutex, mit dem Nachteil dass sich Schläfer und Wecker gegenseitig "verpassen" können. Für diesen Anwendungszweck nicht zu empfehlen.

Die Klasse cMutexLock nun macht nichts weiter als einen ihr übergebenen cMutex zu sperren, bis die Lebenszeit des cMutexLock aufgebraucht ist.

cMutex my_mutex;
void Thread1(void) {
    cMutexLock lock(&my_mutex);
    ...
} // <- die Zerstörung von "lock" bewirkt eine Entsperrung von "my_mutex"

So, nun macht das Beispiel zu cCondVar wahrscheinlich schon _fast_, was Du möchtest. In diesem Fall könntest Du statt my_condvar.Wait(&my_mutex) my_condvar.TimedWait(&my_mutex, 1000) benutzen, dann würde Thread1 die Kontrolle in jedem Schleifendurchlauf an Thread2 abgeben, und zwar für maximal 1000 ms (oder bis Thread2 den ersten weckt).

P.S.: Habe mich wirklich bemüht es verständlich zu machen, aber Threading ist stellenweise ein schwer verständliches Feld

Hm, der Lord war wieder mal schaneller.

Trotzdem hier noch ein link

Ah nochwas:

Klar gibts unter Linux auch echte Warteschlangen, allerdings nicht im Kontext der schönen VDR-Klassenhierarchie

Nunja, das meiste habe ich aus Erfahrung gelernt

Angefangen hab ich mit C schon auf dem Amiga (ca. 1992), damals mit einem hervorragenden Anfängerkurs in der AmigaDOS :D, dessen Autor mir auch einige Jahre lang ein guter Mentor war :]. Der Rest kam dann mit der Erfahrung, und wohl auch zu einem grossen Teil von meiner Neugier. Ich glaube es gibt nicht viele die bei Langeweile einfach mal fürs Üben kleine Frameworks schreiben oder Referenzen studieren :D. Ich will halt nicht nur wissen wie es funktioniert sondern auch stets wieso es so funktioniert...

Hi!

Danke Sascha. Also das hat mich auch schon immer interessiert wofür man diese vielen Klassen brauchen könnte ... toll dass du das mal zusammengefasst hast ... das hilft mir sicherlich mal bei der ein oder anderen Problemstellung.

Zitat

Original von LordJaxom
Klar gibts unter Linux auch echte Warteschlangen, allerdings nicht im Kontext der schönen VDR-Klassenhierarchie

Meinst du da die STL::queue? Oder wäre das was anderes wo man sich nicht um das Locken usw. kümmern müsste? Aber um das wird man ja wohl nicht herumkommen nehme ich an ...

Gruß,
Brougs78

Nee, stl::queue is ne Queue, keine Warteschlange (steht ja nix von "wait" im Namen ;D)

Ich spreche von den althergebrachten System V IPC Message Queues.