- 3D-Druck Einstieg und Tipps         
Seite 1 von 10 123 ... LetzteLetzte
Ergebnis 1 bis 10 von 94

Thema: pthread: was genau macht "joinable" und was macht "detached"?

  1. #1
    HaWe
    Gast

    pthread: was genau macht "joinable" und was macht "detached"?

    Anzeige

    Praxistest und DIY Projekte
    hi
    ich verstehe noch nicht den genauen Unterschied bei pthread:
    was genau macht "joinable" bzw. pthread_join mit einem thread, wenn er sich beendet hat (oder wurde),
    und was macht "detached"?

    aktueller Anlass:
    üblicherweise laufen fast alle meine threads in einer Dauerschleife (while (active) { // loop} ),
    und wenn active extern auf 0 gesetzt wird, werden alle threads beendet und per pthread_join "gejoined" (was immer dann damit passiert).

    was aber, wenn sich ein solcher thread aufhängt und daher von main() beendet, alle Einstellungen resettet und dann neu gestartet werden muss?
    Geht das auch mit meinen "normalen joinable" threads, oder muss ich sie von vorn herein als detached ausführen?

  2. #2
    Erfahrener Benutzer Roboter-Spezialist Avatar von schorsch_76
    Registriert seit
    25.03.2012
    Ort
    Kurz vor Neuschwanstein
    Alter
    48
    Beiträge
    456
    Hallo HaWe,

    ein thread ist ein paralleler Ablauf "Faden".

    joinable() gibt an, ob der Thread bereit ist für einen join(). Das ist er bsp. wenn er läuft oder er seine thread Funktion beendet hat (mit return oder einfach die Funktion verlassen hat).

    Ein Thread ist nicht joinable(), wenn er detached gestartet wurde. Detached bedeutet, dass er sozusagen im Hintergrund in deinem Programm läuft. Dein Handle ist dann nicht mehr gültig und du hast keine "Verbindung" mehr zu ihm, außer dass du eventuell Syncronisationsobjekte oder atomare Variable hast, mit dem du mit ihm kommunizierst. Du machst einen Thread detached, wenn du dich nicht um seine Lebenszeit kümmern willst. ABER: Bei Programende must du doch irgendwie dafür sorgen, das er sauber beendet wird.

    Meine Empfehlung: Starte ihn joinable und kümmer dich um seine Lebenszeit.

    Bei boost [1] oder bei cppreference [2] kannst du noch mehr darüber erfahren.

    [1] https://www.boost.org/doc/libs/1_70_...ml/thread.html
    [2] https://en.cppreference.com/w/cpp/thread/thread

  3. #3
    HaWe
    Gast
    dankeschön, also wäre joinable die bessere Strategie...
    join aber haißt doch "beitreten, verbinden" -
    am Schluss will ich ihn aber doch beenden (gerade wenn er sich aufgehängt hat, um ihn dann neu zu starten):
    wieso dann "join=beitreten" - mir ist das Konzept hinter join noch nicht klar....

  4. #4
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    39
    Beiträge
    3.416
    join aber haißt doch "beitreten, verbinden" -
    am Schluss will ich ihn aber doch beenden (gerade wenn er sich aufgehängt hat), wieso dann "join" - mir ist das Konzept hinter join noch nicht klar....
    Um deinen Thread "normal" zu beenden benötigst du eine "Möglichkeit" die Schleife zu beenden. Dafür gibt es sehr viele Lösungen, aber der Join bezieht sich in erster Linie darauf dass du deinen aktuellen Thread Kontext (von dem aus du den anderen beenden möchtest) mit dem Kontext deines laufenden Thread synchronisierst um dann zum beispiel eine "running" Variable auf false zu setzen.

    Ist dir verständlich warum man Threads beim Datenaustausch synchronisieren muss oder nicht? (das müsste man vieleicht etwas ausführlicher Erklären, da sich daraus ergibt warum man manchmal joinen muss)
    Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
    nicht.

  5. #5
    HaWe
    Gast
    danke, ich vermute, genau das ist der Punkt - wieso muss ich etwas synchronisieren, wenn doch der pthread geendet hat?

  6. #6
    Erfahrener Benutzer Roboter-Spezialist Avatar von schorsch_76
    Registriert seit
    25.03.2012
    Ort
    Kurz vor Neuschwanstein
    Alter
    48
    Beiträge
    456
    Zitat Zitat von HaWe Beitrag anzeigen
    dankeschön, also wäre joinable die bessere Strategie...
    join aber haißt doch "beitreten, verbinden" -
    am Schluss will ich ihn aber doch beenden (gerade wenn er sich aufgehängt hat, um ihn dann neu zu starten):
    wieso dann "join=beitreten" - mir ist das Konzept hinter join noch nicht klar....
    Ja, eher zusammenführen der zwei Anläufe.

    In der Regel nutze ich die C++11 threads.

    Das sieht dann etwa so aus:

    Code:
    #include <thread>
    #include <atomic>
    #include <iostream>
    
    std::atomic<bool> thread_run { true };
    void execute()
    {
        int i = 0;
        while (thread_run.load())
        {
            // do work
            std::cout << "Hello from Thread: " << i++ << std::endl;
            std::this_thread::sleep_for(std::chrono::seconds(1));
        }  
    }
    
    int main(int argc, char** argv)
    {
        std::thread worker(&execute);
        std::this_thread::sleep_for(std::chrono::seconds(5));
        thread_run = false;
        if (worker.joinable())
        {
            worker.join();
        }
        return EXIT_SUCCESS;
    }
    g++ main.cpp -lpthread
    georg@hammerhead /tmp ./a.out
    Hello from Thread: 0
    Hello from Thread: 1
    Hello from Thread: 2
    Hello from Thread: 3
    Hello from Thread: 4

  7. #7
    HaWe
    Gast
    danke, wie es geht mit pthread_join(), das weiß ich -
    mir ist nur nicht klar, wieso "join" und nicht z.B. "stop" oder "kill"...?
    was muss da gejoint oder gesynct werden?

  8. #8
    Erfahrener Benutzer Roboter-Spezialist Avatar von schorsch_76
    Registriert seit
    25.03.2012
    Ort
    Kurz vor Neuschwanstein
    Alter
    48
    Beiträge
    456
    Der Linux Scheduler hat jetzt 2 Einträger in seiner Taskliste die er abarbeiten muß. Beim beenden muß der Worker wieder gejoint werden um das Programm sauber zu beenden. Wenn der mainthread sich beendet, ruft Linux für deinen Thread kill() auf und beendet ihn auch, nur: Du weißt nicht, in welchen Zustand er beendet wurde. Waren Dateien halb geschrieben? Das interessiert nicht mehr... Jetzt ist schluß.... kill()
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken 2019-06-13-132100_3360x1050_scrot.jpg  

  9. #9
    HaWe
    Gast
    hmmm.... was bedeutet "muß der Worker wieder gejoint werden um das Programm sauber zu beenden"?
    Meinst du mit Worker den timeslice (roundrobin) Scheduler, der alle threads nacheinander aufruft?
    und was daran muss gejoint=beigetreten oder verbunden werden?

    (auf dem Screenshot erkenne ich leider nichts)

  10. #10
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    39
    Beiträge
    3.416
    Einfaches Beispiel, du hast einen Arbeitskollegen (Thread Objekt)

    Dein Kollege arbeitet mit einem Trennschleifer an einer Platte, während du auf einen anderen Teil der Platte was anzeichnest ... solange er arbeitet kannst du ihm zurufen und winken so viel du willst aber er bekommt es nicht mit weil er in seinem Kontext ist (Gehörschutz und Schutzbrille), solltest du in seinen Arbeitsbereich kommen gibts Ärger (Concurrent Access als Fachwort)

    Damit du deinem Kollegen etwas mitteilen kannst, musst du ihm erstmal auf die Schulter klopfen (join) um ihm zu sagen dass die Arbeitszeit rum ist, er kümmert sich dann darum die aktive Aufgabe abzuschließen (den rest der loop bis zum definierten Abbruch), zu fegen und zu gehen.

    Du kannst dem Kollegen auch einfach den Strom abschalten oder ihn abmurksen (kill) aber dann ist die Aufgabe nicht erledigt und überall liegt noch der Staub rum

    Wenn dein Kollege aber schon gegangen ist, kannst du ihm nicht auf die Schulter klopfen (weswegen ich auch nciht verstehe was du damit meinst "einem thread joinen der schon beendet ist" ... das geht eigentlich nicht und sollte einne Fehler geben)

    Detached in dem Kontext wäre, wenn dein Kollege sich in einem Zimmer einschließt und du ihm nicht mehr auf die Schulter klopfen kannst aber auch nicht mehr direkt weist ob er überhaupt noch da ist!

    Deswegen sind Threads auch nur ein Konstrukt, aber du musst dir halt noch Mühe machen den Thread zu steuern und die Steuerung selber implementieren! (Arbeitsanweisung als Beispiel, bei rotem Licht arbeit einstellen, aufräumen und nach Hause gehen ... wie das rote Licht in deinem Fall implementiert ist, bleibt dir überlassen)

    PS: Threads haben komplexere Strukturen im Speicher als du vermuten magst und deswegen gibts es Einschränkungen miteinander zu kommunizieren ... du weist schließlich nicht was dein Kollege denkt, nur das was er sagt und macht. (Die Rote Lampe muss natürlich Thread-Safe sein ... eine Atomic Variable wie es schon oben geannt worden ist, ein Mutex der verhindert dass 2 Threads "gleichzeitig" auf die selber Variable zugreifen .. oder du klopfst dem Kollegen auf die Schulter damit du den Schalter der roten Lampe an seinem Platz anmaschen kannst ohne in sein Arbeitsbereich einzugreifen)
    Geändert von Ceos (13.06.2019 um 13:52 Uhr)
    Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
    nicht.

Seite 1 von 10 123 ... LetzteLetzte

Ähnliche Themen

  1. Antworten: 10
    Letzter Beitrag: 01.11.2017, 13:53
  2. Antworten: 2
    Letzter Beitrag: 15.06.2011, 22:18
  3. "Optimization" macht debuggen schwer
    Von yaro im Forum C - Programmierung (GCC u.a.)
    Antworten: 2
    Letzter Beitrag: 05.02.2010, 21:40
  4. "Soft-Reset?" und "Finger-Interrupt?"
    Von trapperjohn im Forum Asuro
    Antworten: 8
    Letzter Beitrag: 11.06.2008, 00:02
  5. ASM: was machen "swap" und "cbr" genau?
    Von RHS im Forum AVR Hardwarethemen
    Antworten: 3
    Letzter Beitrag: 18.08.2004, 18:16

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiFePO4 Speicher Test