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

[HaWe]

Um so etwas komplett "abschiessen" zu können wäre ein Child Process [3][4] möglich. Damit könntest du das komplett abschießen und neu starten (Forken). Die Kommunikation würde dann über bsw. Fifo [2] laufen.

Ich empfehle dir das Buch: "The Linux Programming Interface: A Linux and UNIX System Programming Handbook"

Leider geht es nicht ohne Theorie. Wenn die Praxis nicht zur Theorie passt, läuft alles total schief und führt zu den verschiedensten Problemen. Computer verhalten sich nun mal nur logisch nach den definierten API's. Bsw. Posix.

[1] ISBN-13: 978-1593272203: The Linux Programming Interface: A Linux and UNIX System Programming Handbook
[2] https://linux.die.net/man/4/fifo
[3] https://linux.die.net/man/2/fork
[4] http://man7.org/linux/man-pages/man2/kill.2.html

Leider auch nur sehr theoretisch, die man pages kenne ich überwiegend schon; außerdem arbeite ich mit wiringPi und seinen file wrappern und seinen handles/fd's, nicht mit nativen files.
Was ich inzwischen aber heraus bekommen habe:
wenn ein realtime thread mit SCHED_RR prio 40 oder 50 hängt (Bereich: 0-99), komme ich auf einem single core Raspi (B+, Zero) überhaupt nicht mehr an irgend etwas heran: das gesamte Programm blockiert dann vollständig.
Auf einem multicore (2B, 3B) geht das schon besser, dann muss es aber wschl von einem höherwertigen thread aus passieren.
Unklar ist, wie SCHED_FIFO / _OTHER etc threads vom Scheduler behandelt werden gegenüber dem hängenden thread, und von einer main() loop aus wird es möglichereise auch nicht gehen, wenn weitere high prio threads laufen, denn (edit) die main loop läuft mit nice=0 (+20...-19, vergleichbar mit SCHED_OTHER (by default), hier gibt es keine prios), und kein Mensch weiß offensichtlich, wie die prios und nices untereinander verrechnet werden ).
Es wird also per zusätzlichem "watcher_thread" laufen müssen, d.h. von einer höheren SCHED_RR prio aus, und es dürfen wschl KEINE SCHED_FIFO threads laufen, wozu du verlinkt hast.

Er muss dann also über einen Thread mit SCHED_RR prio >50 laufen, der alle anderen überwacht (edit: z.B. prio 70-90, aber langen delays/yields zwischendurch),
von dort den anderen mit thread_kill() abbrechen,
dann UART (fd=Serial) beenden,
dann zusätzlich joinen, damit der threadID Handle gelöscht wird,
alles an Variablen /Semaphoren zurücksetzen,
dann UART (fd=Serial) sicher neu starten (geht das?),
dann den vorher abgebrochenen Thread neu starten (geht das mit dem früheren fd=Serial und der früheren threadID, jetzt neu zu vergeben?)
und dann muss die UART Verbindung sich neu mit dem Arduino re-syncen (geht das, auch wenn zwischendurch der virtuelle USB COM Port weg war?)

Ich vermute, viele wird es hier nicht geben, die sich mit der Materie tatsächlich auskennen und einen sicheren Beispielcode posten können, auch wenn ich es gehofft hatte...

[schorsch_76]

...
Ich vermute, viele wird es hier nicht geben, die sich mit der Materie tatsächlich auskennen und einen sicheren Beispielcode posten können, auch wenn ich es gehofft hatte...

HaWe: Ich mache das seit 20 Jahren in C++. Jeden Tag. Hier zeige ich dir die Richtung die gangbar ist, aber ich werde dir nicht dein Projekt schreiben.

[HaWe]

HaWe: Ich mache das seit 20 Jahren in C++. Jeden Tag. Hier zeige ich dir die Richtung die gangbar ist, aber ich werde dir nicht dein Projekt schreiben.

a ja, danke, aber die "Richtung" ist mir doch klar...
(gedacht war es ja für das Community Projekt RP6-Nachfolger, da wäre also Mitarbeit mit "echtem Code" auch für alle anderen sehr nützlich...)

(PS, edit: irgendwie "hinwurschteln" kann ich es ntl, die Frage ist nur, wie man es richtig und möglichst failsafe macht)

[schorsch_76]

Ich kann heut Abend ein kleines Sample schreiben

EDIT:
Das mit dem Subprozess kann sicher auch nach einem wegbrechen des ttys wieder starten. Wenn der tty einfach nicht mehr zu öffnen ist, dann wird auch das nichts werden.

Um das Arduino Protokol wieder zu syncen, muss halt das Protokoll "syncbar" sein. Der Arduino hat ja nichts davon mitbekommen.

Wie schaut denn das Protokoll aus?

[HaWe]

Ich kann heut Abend ein kleines Sample schreiben

EDIT:
Das mit dem Subprozess kann sicher auch nach einem wegbrechen des ttys wieder starten. Wenn der tty einfach nicht mehr zu öffnen ist, dann wird auch das nichts werden.

Um das Arduino Protokol wieder zu syncen, muss halt das Protokoll "syncbar" sein. Der Arduino hat ja nichts davon mitbekommen.

Wie schaut denn das Protokoll aus?

dankeschön!
das Arduino-Prog iat hier: https://www.roboternetz.de/community...l=1#post652616

- - - Aktualisiert - - -

dankeschön!
das Arduino-Prog iat hier: https://www.roboternetz.de/community...l=1#post652616

meine grobe Idee war (der heart beat ist noch nicht ausformuliert, nur der thread kill):

void* WATCHER_thr(void*)           // very high priority:  thread watcher  
{ 
   while(_TASKS_ACTIVE_) {               

    // to do: UART_HEARTBEAT auswerten!

    if (!UART_HEARTBEAT) {  // delays sind nur grobe Ideen, als yield für andere threads!
       pthread_kill(thread2, SIGKILL); // does not erase handle!
       delay(10);  // zusätzlich weitere Wartebedingung für kill?

       pthread_join(thread2, NULL);  // join, erase handle
       delay(10);

       serialClose( Serial);  // close UART, fd=Serial
       delay(10);
       Serial = serialOpen (uart, UARTclock);    // re-open Serial
       delay(1);
  
       pthread_create(&thread2, NULL, UART_thr, NULL);    // restart UART by medium   
       param.sched_priority = 40;
       pthread_setschedparam(thread2, SCHED_RR, &param); 

       delay(10);
    }
     
    delay(100);  // long yield

   }         
   return NULL;
}

// andere treads siehe Link oben!

//==================================================================
//==================================================================
 
int main() {
    
    // threads    
    pthread_t  thread0, thread1, thread2;
    struct     sched_param  param;
    
    printf("starting ..."); printf("\n");   
    
    // open UART Serial com port    
    Serial = serialOpen (uart, UARTclock);       
        

    // start multithreading  
    pthread_create(&thread0, NULL, WATCHER_thr, NULL);     // very high priority: thread watcher 
    param.sched_priority = 80;
    pthread_setschedparam(thread0, SCHED_RR, &param);
    
    pthread_create(&thread1, NULL, KBD_thr, NULL);     // low priority: keyboard monitor 
    param.sched_priority = 40;
    pthread_setschedparam(thread1, SCHED_RR, &param);
   
    pthread_create(&thread2, NULL, UART_thr, NULL);    // medium  priority: UART
    param.sched_priority = 40;
    pthread_setschedparam(thread2, SCHED_RR, &param);    
     
    
    while(_TASKS_ACTIVE_) { delay(10); }
     
    // wait for threads to join before exiting
    pthread_join(thread1, NULL);
    pthread_join(thread2, NULL);
    pthread_join(thread3, NULL);
   
    serialClose( Serial);
    exit(0);
}

[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.