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

[HaWe]

@HaWe: Das hier ist der komplette Code der Laufen soll?


Dazu soll dann noch vermutlich IO vom PI?

Hier kann man ASCII malen
http://stable.ascii-flow.appspot.com

hallo,
das ist erst die Basis, die tokens werden dann ausgewertet und als Sensorwerte verarbeitet oder die entsprechenden GPIOs geschaltet.
Dadurch stehen dann dem Raspi zusätzlich z.B. die 16 ADCs und die 54 digital GPIOS des Mega zur Verfügung plus die Peripherie, die am Mega angeschlossen ist.
Es kommen dann weitere threads hinzu, z.B. für Encder lesen, Navigation aus Odometrie und IMU+GPS, Fernsteuerung, Bildschirmanzeige, PID-Regler, autonome Aktionen wie Wegefindung u/o SLAM.

PS,
ich bin an einer Sache dran, kritische threads asynchron zu starten und mit pthread_cancel ggf. zu stoppen...

[schorsch_76]

Da du pthread_cancel ansprichts, hier gibt es etwas zu lesen für dich:
https://lwn.net/Articles/683118/

Das Problem das ich hier eben sehe, das mein Design mit den Prozessen nicht hat, sind nicht frei gegebene Betriebsystemresourcen wie bsp der offene Filedescriptor für ttyACM0. Da dein Projekt ja der RB6 ist und er recht lange laufen soll, könnte es passieren dass deinem Prozess die Filedescriptoren aus gehen, wenn diese nicht frei gegeben werden. Den Wert kann man erhöhen. Standardmäßig ist er glaub 1024, aber er kann nicht beliebig hoch gesetzt werden wegen begrenzter Resourcen auf dem Zielsystem.

Zur Erklärung ein Beispiel:
Wenn der ttyACM0 vom USB abgezogen wird, während der Thread hier einen Handle hat (auch wiringPi setzt auf dem Kernel auf), ist der FD immer noch offen. Du machst pthread_cancel und restart und du hast 2 offene FD's. Den alten und den neuen FD. Zumindest in der Filedescriptor Tabelle des Prozesses. Das kannst du sehen wenn du ein "ls /proc/${deine PID}/fd" ansiehst.

Da das Projekt auf dem Pi noch recht am Anfang steht, würde ich das versuchen zu beachten. Wenn du sagst, das ist für dich kein Thema, dann ok

[HaWe]

hallo,
danke für die Infos!
den int fd bekomme ich über wiringSerial: ich öffne ja UART per fd=serialOpen("/dev/ttyACM0", clock);
und wenn ich den Thread abbrechen musste, hänge ich sicherheitshalber noch ein serialClose(fd) hinten dran - dann müsste ja der fd wieder gelöscht/freigegeben sein, oder?

(erst danach öffne ich dann per fd=serialOpen("/dev/ttyACM0", clock) erneut.)


edited

[schorsch_76]

Das könnte klappen...

Du musst dich aber um alle Resourcen kümmern. Am besten alles im Heap halten dann bei Close(fd) auch freigeben. std::string und co jegen große Sachen aber auch im Heap ab. Damit wird der Speicher voll und voller...

Edit: Heap: Frei Speicher.

std::string* buffer = new std::string;

beim Freigeben

Close(fd);
delete buffer;
...

[HaWe]

abere signore, isch 'abe doche gare keine std::threade

[schorsch_76]

Das ist egal, auch dein pthread den du mit pthread_cancel abbrichst, muss die Resourcen frei geben.

[HaWe]

theoretisch klar, aber ich weiß nicht wie, andererseits: so viel reservierten Speicher gibt es ja gar nicht.

Ich kann auch einige Variablen sicherheitshalber global deklarieren.

[Klebwax]

Da du pthread_cancel ansprichts, hier gibt es etwas zu lesen für dich:
https://lwn.net/Articles/683118/

Das Problem das ich hier eben sehe, das mein Design mit den Prozessen nicht hat, sind nicht frei gegebene Betriebsystemresourcen wie bsp der offene Filedescriptor für ttyACM0.

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

[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