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

[HaWe]

Das ist ein grundsätzliches Problem. Am Anfang glaubt man, man kann sich die Interprozesskommunikation sparen, wenn man Threads statt Tasks benutzt. Man kann einfach globale Variable verwenden. Dazu kommt noch die verbreitete Meinung, Taskwechsel verschenken Zeit gegenüber Threadwechseln. Irgendwann, wenn das System unübersichtlich geworden ist und sich z.B. die ersten Memoryleaks oder Deadlocks eingeschlichen haben, fängt man an, eine Thread- und Speicherüberwachung zu programmieren. Zum Schluß stellt man dann fest, daß man ein eigenes Betriebssystem programmiert hat, das aber längst auf dem System vorhanden ist. Das eigene ist auch nicht einfacher als das vorhandene, dafür ist es nur von einem selbst getestet und es fehlen hunderte Seiten man-Pages. Wer schreibt schon sowas zum eigenen Code? Wegen der Threadüberwachung ist es sogar langsamer als ein System, das auf Tasks basiert.

Daher sollte man am Anfang des Systemdesigns gut überlegen, ob es Sinn macht, ein eigenes Tasking-System (genauso wie eigene Kommunikationsprotokolle oder eine eigene Datenserialiesung) zu erfinden. Am Ende lauert immer das komplette Fiasko.

MfG Klebwax

dein Einwand trifft hier nicht zu, denn wegen (höchstwahrscheinlich) kernel Zugriffen funktioniert hier keine UART Kommunikation über Stunden hinweg stabil in einer main loop (es hatte sich ja immer aufgehängt nach mehreren Minuten, wenn du dich recht erinnerst) , und wenn mal eine main loop hängen sollte, ist dann komplett Hopfen und Malz verloren.
Außerdem ist aber ja doch das gesamte Prgrommdesign eh auf MT ausgelegt (SCHED_RR mit verschiedenen prios).
Die Threadüberwachug aber läuft zwar in einem high prio Thread, aber später mit langen yields/delays von mindestens 100ms pro loop (oder noch viel länger), die auf einem quadcore überhaupt nicht ins Gewicht fallen, zumal die yield Zeiten in vollem Umfang vom Scheduler den anderen time slices zur Verfügung gestellt werden.

- - - Aktualisiert - - -

PS
oder habe ich deinen Bezug falsch intepretiert?

[Klebwax]

dein Einwand trifft hier nicht zu, denn wegen (höchstwahrscheinlich) kernel Zugriffen funktioniert hier keine UART Kommunikation über Stunden hinweg stabil in einer main loop (es hatte sich ja immer aufgehängt nach mehreren Minuten, wenn du dich recht erinnerst) , und wenn mal eine main loop hängen sollte, ist dann komplett Hopfen und Malz verloren.
Außerdem ist aber ja doch das gesamte Prgrommdesign eh auf MT ausgelegt (SCHED_RR mit verschiedenen prios).
Die Threadüberwachug aber läuft zwar in einem high prio Thread, aber später mit langen yields/delays von mindestens 100ms pro loop (oder noch viel länger), die auf einem quadcore überhaupt nicht ins Gewicht fallen, zumal die yield Zeiten in vollem Umfang vom Scheduler den anderen time slices zur Verfügung gestellt werden.

Du hast meinen Text nicht wirklich verstanden. Daher hier noch mal die wichtigsten Worte

Threads statt Tasks

MfG Klebwax

Da du deinen Text ergänzt hast hier meine Ergänzung: Ja

[HaWe]

meintest du mit Tasks die Prozesse und Sub-Prozesse mit dem pipe Ding von schorsch?

[schorsch_76]

@HaWe: Genau: Er meint man sollte die Aufgaben in einzelne Prozesse verlagern. Auch die Prozesse werden vom Scheduler des Betriebsystems richtig priorisiert.

[Klebwax]

@HaWe: Genau: Er meint man sollte die Aufgaben in einzelne Prozesse verlagern.

So einfach hab ich das nicht gesagt. Ich hab gesagt, daß man sich die Entscheidung ob Task oder Thread (oder auch beides) nicht zu leicht machen sollte. Ein Designfehler an dieser Stelle kann zum völligen Fehlschlag des Projektes führen.

Auch die Prozesse werden vom Scheduler des Betriebsystems richtig priorisiert.

"Auch" halte ich hier für eine unglückliche Formulierung. Unix, und das gilt auch für seine seine Clones, ist ein Multitasking System mit gekapselten Prozessen, die in eigenen Adressräumen laufen. Erst später sind Threads dazu gekommen. Der Scheduler kümmert sich also primär um Tasks und erst in zweiter Linie um die Threads der Tasks. Er arbeitet auch, wenn, wie früher. kein einziger Thread aufgesetzt wird.

MfG Klebwax

[HaWe]

ist es nicht so, dass seit den POSIX C Definitionen insb. zu pthread (irgendwann schon in den 90ern) das MT per pthread eingeführt wurde?
Ich arbeite ja mit pthread, und seit C99 spätestens ist das ja Standard.
Übrigens, ich habe jetzt erfolgreich eine Methode getestet, die ich von einem netten Forumsmember des Raspi Forums bekommen habe (Paeryn).
Ist zwar auch nicht gerade leichte Kost, aber fügt sich prima in meine pthread MT Architektur ein!
Und: Es klappt jetzt damit mit dem Abbrechen eines einzelnen Threads!

Jetzt will ich sehen, ob ich ihn auch wieder starten kann und dann ob das auch auf die UART Kommunikation ausgeweitet werden kann...

// Quelle. https://www.raspberrypi.org/forums/posting.php?mode=quote&f=33&p=1481807
#include <stdio.h>
#include <pthread.h>
#include <stdbool.h>
#include <unistd.h>
#include <stdlib.h>

volatile bool TASKS_ACTIVE = false;
volatile bool HEARTBEAT = false;

// This is the cleanup function for UART_thr, it will be called if the
// thread is cancelled or exits via pthread_exit(). Use it to release any
// resources the thread has.
void UART_thr_cleanup(void* data)
{
    printf("UART_thr cleanup.\n");
}

void* UART_thr(void* data)          // UART comm (now just stalling)
{
    int old;
    if (pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, &old)) {
        printf("UART: Error setting async cancel state.\n");
        pthread_exit(NULL);
    }
    pthread_cleanup_push(UART_thr_cleanup, NULL);
    HEARTBEAT = true;
    for(int i = 0; i < 5; i++) {
        printf("UART: i = %d\n", i);
        sleep(1);
    }
    printf("UART: simulating stall\n");
    HEARTBEAT = false;
    while(1) ;  // mimics stalling forever
    pthread_cleanup_pop(true);
    return NULL;
}


// We pass in a pointer to the thread id which we may need to cancel
void* WATCHER_thr(void* heartbeat_id)           // thread watcher
{
    pthread_t heartbeat_thread_id = *(pthread_t*)heartbeat_id;
    bool THREAD_ACTIVE = true;
    printf("WATCHER: Checking heartbeat.\n");
    while(THREAD_ACTIVE)  {  //
        //  cancel UART thread if no heart beat detected
        if(!HEARTBEAT) {
            //  cancel UART thread  // <~~~~~~~~~ ????  pthread_kill ? pthread_cancel ?
            printf("WATCHER: Lost heartbeat, cancelling UART thread.\n");
            pthread_cancel(heartbeat_thread_id);
            THREAD_ACTIVE = false;
        }
    }
    TASKS_ACTIVE = false;
    return NULL;  //
}


//

int main() {

    // threads
    pthread_t       thread0, thread1, thread2;
    pthread_attr_t  thread_attr;
    struct sched_param   param;

    // start multithreading
    pthread_attr_init(&thread_attr);  // Initialise the attributes
    pthread_attr_setschedpolicy(&thread_attr, SCHED_RR);  // Set attributes to RR policy

    param.sched_priority = 40;
    pthread_attr_setschedparam(&thread_attr, &param); // Set attributes to priority 40 (policy is already RR)
    pthread_create(&thread2, &thread_attr, UART_thr, NULL);    // medium  priority: UART

    param.sched_priority = 80;
    pthread_attr_setschedparam(&thread_attr, &param); // Set attributes to priority 80
    pthread_create(&thread0, &thread_attr, WATCHER_thr, &thread2);     // high priority: heartbeat monitor

    pthread_attr_destroy(&thread_attr); // We've done with the attributes

    TASKS_ACTIVE = true;
    while(TASKS_ACTIVE) {
        printf("MAIN: tasks active, waiting\n");
        sleep(1);
    }
    printf("MAIN: threads ended, goodbye.\n");

    // wait for threads to join before exiting
    pthread_join(thread0, NULL);
    //pthread_join(thread1, NULL);
    pthread_join(thread2, NULL);

    exit(0);
}

[Klebwax]

ist es nicht so, dass seit den POSIX C Definitionen insb. zu pthread (irgendwann schon in den 90ern) das MT per pthread eingeführt wurde?

Nein.
Das wäre ja ein Schritt zurück zu Windows 3.11 mit darunter liegendem DOS ohne Speicherschutz. Ich zitiere mal hier (Prozess und Task sind Synonyme)

What is a Thread?
A thread is a single sequence stream within in a process. Because threads have some of the properties of processes, they are sometimes called lightweight processes.

What are the differences between process and thread?
Threads are not independent of one other like processes as a result threads shares with other threads their code section, data section and OS resources like open files and signals. But, like process, a thread has its own program counter (PC), a register set, and a stack space.

Ein Thread kann also den anderen Threads den Code überschreiben, in den Speicher schreiben oder auch einen File schließen. Das macht einem im positiven Fall das Leben leichter (keine Interprozesskommunikation nötig) bringt aber im negativen Fall alle Threads gemeinsam zum Absturz.

MfG Klebwax

[HaWe]

wieso schreibst du jetzt was zu Windows? Windows ist a-priori nicht POSIX-kompatibel.
Tatsächlich (habe nachgeguckt) is threads eine Standard POSIX Extension seit 1995:

Threads is an API defined by the standard POSIX.1c, Threads extensions (IEEE Std 1003.1c-1995).

https://en.wikipedia.org/wiki/POSIX_Threads

Aber lassen wir das mit der Historie und den Grundsatzdiskussionen:
pthread ist ANSI C99 Standard, pthread ist relativ einfach anzuwenden (sogar einfacher als std::thread finde ich), und es ist seit langem erprobt, bewährt und ohne Bugs.

Ich bn ja selber kein ausgebildeter Programmierer sondern Laie und Hobby-Anwender, und als Laie kann ich sagen, dass man sich zwar schon einarbeiten und etliche Fragen klären muss, aber wenn man das tut, dann ist es auch für Laien anwendbar (das ist mit den ganzen Fuses und Interrupts in avrstudio sicher nicht anders).
Immerhin ist pthread zur Implementierung deutlich weniger komplex als Subprozesse, daher würde ich pthread in jedem Falle den Vorzug geben.

[oberallgeier]

.. Ich zitiere mal hier (Prozess und Task sind Synonyme) ..

Danke für so ne Quellenangabe. Für mich sind "joinable", "detached", Thread, Prozess, Task etc im Kontext zu Programmen bzw. Programmierung eher Fremdwörter in denen ich nur sehr bescheidene Inhalte sehe, von irgendeinem Wissen zu Systemdesign mal ganz abgesehen. Das ist sehr persönlich - leider. Aber genau deswegen lese ich so etwas intensiv mit in der Hoffnung dass mal ein Schimmer aufleuchtet. Dein Link hilft da (ungemein?), danke. Und jetzt schweige ich hier wieder und lese nur noch.

[HaWe]

PS, back to topic:
ein wenig klarer ist es mir ja jetzt geworden, was "pthread_join" macht, nach meinem begrenzten Verständnis, in einfachen Worten (nicht Expertenmode-sicher ):
- es wird im eigentlichen Wortsinn nichts von den ursprünglichen Thread-Funktionen (Thread-Code) gejoint, d.h., der Thread selber "tritt main() nicht bei" bzw. "hängt sich main() nicht an".
- es wird auch kein Thread sicher beendet, sondern nur darauf gewartet, dass der Thread endet
- dennoch müssen hnterher noch Speicher und Pointer etc. aufgeräumt werden, z.B. existiert immer noch ein thread-Handle über die thread-ID, und auch die wird erst durch pthread_join gelöscht.
- auch wenn der Thread sich nicht selber beendet, sondern er über pthread_cancel beendet wurde, ist der Thread handle noch nicht geschlossen, auch das muss noch durch ein zusätzliches pthread_join erledigt werden.