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

[Ceos]

Wenn man richtig Bare Metal programmiert ist das möglich, Wenn man Arduino nutzt muss man halt mit den Schwächen leben oder sich intensiver damit befassen und einen Workaround entwickeln oder finden!

was ist wenn das UART-USB- Kabel abgeht

Das kann man Problemlos erkennen, wenn man Kontrolle über den USB Stack hat bzw. weis wie die Peripherie des Chip arbeitet

oder doch wieder der kernel dazwischenfunkt

was hat das bitte mit read() und available() auf Controllerseite zu tun, das ist abwegig! Oder du meinst etwas anderes...

und zu einem timeout führt (edit: wie vorher in der singlethread-Version)?

wenn available == 0 dann sperrt read oder bekommt ein timeout wenn man das einstellen kann (hab ich gerade keine ahung unter arduino was das angeht)
wenn available > 0 dann sperrt read 100% nicht!

Oder der Arduino aus irgendeinem unbekannten Grund temporär den USB blockiert?

Das ist ein ARduino Problem und der einzige Weg wäre Arduino nicht zu nutzen!

Ich hab doch im ersten Satz geschrieben das es die Kunst des Programmierens ist ... Wenn ich einen Vergleich zwischen Arduino und echtem Bare Metal programmieren ziehen müsste, würde ich sagen, Bare Metal ist mit Pinsel und Leinwand während Arduino Photoshop und einen Drucker sind.
Dein Photoshop(Arduino) kann hängen bleiben und dein Drucker(Board Lib für Arduino) kann abstürzen oder falsch arbeiten.
Beim Zeichnen mit Pinsel und Leinwand entscheidet nur die Erfahrung, Übung und die Qualität der Leinwand(Controller/Board) über das Ergebnis.

Wenn man Bibliotheken nutzt, muss man sich mit den Schwächen abfinden oder eben selber das Konzept verstehen und entweder den Fhler an der Lib beheben oder selber eine schreiben.

Aber da rutschen wir gerade in eine Grundsatzdiskussion ab also lassen wir das Thema lieber, ich wollte dir nur klarmachen dass es absolut vermeidbar ist wenn man auf Komfort verzichtet. (ohne genauer auszuführen was ich mit Konfort meine)

[HaWe]

es geht um Raspi code, nicht um Arduino-Code!
SerialAvailable() aus der wiringPi lib arbeitet nicht zuverlässig, um solche Fehler eindeutig zu lokalisieren, und auch timeouts tun es nicht, das habe ich schon mit diversen Tests (aus dem Raspi C++ Unterforum) herausgefunden. und wenn Raspi und Arduino im Robot verbaut sind und der Robot herumfährt und folglich der direkten Beobachtung entzogen ist, kann man den Grund für eine Verbindungsunterbrechung nicht unbedingt erkennen.
Es geht hier mit dem Beenden und Neustart eines Threads also lediglich um den automatisierten Versuch des autonomen Programms, den momentanen Fehler (z.B. kein Thread-heartbeat mehr) mit Bordmitteln selber zu händeln.
Einer davon soll sein:
den hängenden Thread stoppen (schrittweise: erst pthread_exit(), wenn erfolglos: pthread_kill(), dann das Serial file zu schließen, Variablen zu resetten, und dann das Serial file neu zu öffnen und den Thread neu zu starten.

Erfahrungsgemäß treten solche Fehler ab und an nicht nur bei UART sondern auch bei I2C auf, auch dafür soll eine solche Notfallmaßnahme implementiert werden.

[Ceos]

Ach verdammt schon wieder mental verrutscht ... Ich war schon wieder bei Arduino Code sorry

Aber das macht es ja sogar noch einfacher, da der Kernel eigentlich alle Funktionen bereitstellt um auch das USB-Detach zu erkennen ... dass der Kernel beim read dazwischen Funkt und man das nicht erkennen kann fällt für mich unter die Kategorie "Kernel Bug" und damit muss man halt leben.

Aber dass die WiringPi Lib notorisch Buggy ist sollte bekannt sein. Es wird ja kontinuierlich dran gebastelt von vielen Köchen (dazu habe ich schonmal was gesagt)

Wenn du statt der Wiring Pi direkt die Kernelfunktionen benutzt hast du auch hier die volle Kontrolle!

UART lässt sich auch ganz bequem per open("/dev/ttyXXXX") erledigen aber dazu müsstest du dich ein wenig tiefer in Linux versetzen

In Lnux wird jede Peripherie und USB Gerät durch den entsprechenden Kernel-Treiber in das Dateisystem projeziert. Es ist die Qualität des Treibers die entscheidet was für Funktionen man nutzen kann, ähnlich wie es die Entscheidung des Hersteller ist wie eine Peripherie in dem entsprechenden Controller integriert wird.

Das was bei Linux das DAteisystem ist, sind die Steuerregister im Controller und solange man die beherrscht und auch der TReiber die Funktion hergibt, kann man auch hier die volle Kontrolle bekommen.

[HaWe]

ich habe das Gefühl, du argumentierst sehr ins Blaue - hast du jemals selber auf dem Raspi UART mit wiringPi programmiert?
Nur von wiringPi gibt es ja die serialAvailable Funktion.
Was weißt du sonst über die Funktionsweise der wiringSerial Funktionen?

Dass ich aber weiß, wie man UART nutzt, das kannst du schon vorraussetzen, wie du auch problemlos in meinem Arduino-Raspi-UART code nachgucken kannst (https://www.roboternetz.de/community...l=1#post652616) - der läuft ja nun unter Normalbedingungen zusammen mit den kernel Programmen stabil
(ich kann nur nicht garantieren, dass IMMER der kernel nur das tut, was ich vorhersehen kann)

- - - Aktualisiert - - -

PS,

Aber dass die WiringPi Lib notorisch Buggy ist sollte bekannt sein. Es wird ja kontinuierlich dran gebastelt von vielen Köchen (dazu habe ich schonmal was gesagt)

an der WiringPi Lib aber arbeitet nur Gordon Henderson, selbst da irrst du also - es wird über das apt package oder direkt von Gordon's git site bereitgestellt.


Bitte halte dich also ans Topic, und da geht es hier ausschließlich um pthread.

[Ceos]

Einer davon soll sein:
den hängenden Thread stoppen (schrittweise: erst pthread_exit(), wenn erfolglos: pthread_kill(), dann das Serial file zu schließen, Variablen zu resetten, und dann das Serial file neu zu öffnen und den Thread neu zu starten.

Um Threads zu steuern und zu Überwachen gibt es viele Möglichkeiten (besonders beim Mehrkern System):

Join ist die simpelste und ist eigentlich nur Sinnvoll, wenn man kurzlebige Threads hat, welche etwas parallel bearbeiten sollen udn dann ERgebnisse zurücklieefern sollen ... der Master kreaiert 10 Threads die unabhängig rechnen, wärend der Master noch irgendwas erledigt. Damit man dann synchronisieren kann, wendet man dann nacheinander auf alle Worker ein Join an um den Thread mit der Main zu synchronisieren, endet der Thread, fährt der Master mit den nächsten Join fort oder was auch immer er zu tun hat. (Das birgt den Nachteil dass man garantieren muss, dass der Thread niemals in ein Dead Lock geraten kann oder diese Methode ist unbrauchbar!)


Die Methode die für dich sinvoller erscheint sind Steuersignale und eine abbrechbare Thread Schleife ohne irgendwelche Hilfmittel von Thread-Librarys! (Thread librarys mögen verschiedene hilfereiche Funktionen anbieten, aber bisher war das immer mit einem unsauberen Exit behaftet oder mit entsprechend umständlichem try-final Blöcken bzw. einem Custom-Destructor)
Deine Threadschleife braucht 2 Abbruchflags von außen und 1 Zustandsflag nach drausßen. Das erste Abbruchsflag sollte in deinem Code dazu führen dass alles abgeschlossen wird und die Eegebnisse zurück geliefert werden und anschließend über das Zustandsflag signalisieren dass der Thread quasi beendet ist (in etwa wie ich es in dem Beispiel weiter oben beschrieben habe, ein Join nach dem pollen eines "Thread beendet" Signals ist immernoch sinnvoll um Raceing Conditions zu vermeiden, sollte aber i.d.R. nicht länger als ein paar Takte blockieren!)

Es gibt Thread Librarys die bieten entsprechende Abort-Funktionen an, die muss man dann im Thread Objekt selbst überschreiben oder eine Methode anbinden/implementieren, das macht es etwas übersichtlicher!

Aber wenn dein Thread einfach nicht "Thread beendet" zurück meldet musst du dir selbst ein kleines Timeout einbauen und den Thread halt mit Kill beenden!

Join sollte man nur nutzen wenn man auch garnatieren kann dass der Thread in absehbarer Zeit beendet wird oder das Programm hängt sich auf

PS:

hast du jemals selber auf dem Raspi UART mit wiringPi programmiert?
Nur von wiringPi gibt es ja die serialAvailable Funktion.
Was weißt du sonst über die Funktionsweise der wiringSerial Funktionen?

Ja, habe ich ... nutze ich nur nicht gerne weil eben verbuggt aber serial per kernel ist halt auch eine scheiß arbeit.

Ich weis auch so prinzipiell wie es arbeitet, der Code steht auf Github da kann man nachlesen und auch Reports machen wenn einem ein Bug auffällt

Das entscheidende ist dass du noch nicht weist wie Linux arbeitet und deshalb nicht das große ganz und die alternativen siehst .. du argumentiert es sei "unmöglich" exakt formuliert wäre da besseer "es ist für DICH und IM MOMENT unmöglich"

Kunst kommt vom Können und das kann man lernen

[HaWe]

wieder mal sehr theoretisch -
poste lieber mal einen funktionierenden Code, um meinen hängenden pthread mit UART zu stoppen und neu zu starten, aller andere theoretische Krimskrams ist mir ja klar.

wenn der pthread aber komplett hängt, dann empfängt er auch von außen keine Variablen mehr bzw. kann auch nicht auf Semaphore oder interne Variablen reagieren.
Er hängt dann fest wie wenn da nur stünde

while(1);

- - - Aktualisiert - - -
PS,

klar weiß ich, wie man mit Linux programmiert, und Details, die ich nocht weiß, die frage ich nach.
So wie jetzt, aber wie es grob geht weiß ich ja auch - siehe hier:
https://www.roboternetz.de/community...l=1#post652792

- - - Aktualisiert - - -

PS 2:

der Code auf github ist nicht von Gordon sondern inoffiziell von einer dritten Person, was aber von Gordon nicht supportet und auch nicht registriert wird.

[Ceos]

wieder mal sehr theoretsch -

dein Mantra ... mein Mantra kennst du ja, animiere zu denken aber vorgekaut wird nur gegen Bargeld

poste lieber mal einen funktionierenden Code, um meinen hängenden pthread mit UART zu stoppen und neu zu starten

Folgender Code sollte funktionieren, solange du niemals detach aufrufst, sonst musst du dir den native-Handle geben lassen und den Thread mit OS Funktionen abschießen

thread::~thread();

und dein Thread ist beendet! Ausprobiert habe ich es nicht, sondern nur eine Random Thread Doku aus dem Netz gezogen, weil ich üblicherweise den Thread Locksafe schreibe und über new erzeuge und auch selber wieder aufräume.

Ein Thread ist immernoch ein Objekt und wenn du den Destruktor aufrufst wird es beendet und zerlegt.

Wenn du aber Detach aufgerufen hast, hast du keinen Zugriff mehr auf das Objekt und musst es vom OS aus killen.

Danach kannst du den Thread einfach neu erstellen(in deinem Fall etwas problematisch denke ich da er statisch angelegt ist).

Wenn dein Thread bekannterweise instabil und DeadLock lastig ist, solltest du ihn vielleicht nicht statisch sondern über new und Objektpointer erzeugen! (Kann mich gerade nicht erinnern was davon "auf dem heap" und was davon "auf dem stack" angelegt wird XD aber ich hoffe du verstehst was ich meine)

PS: https://github.com/WiringPi/WiringPi auch wenns offiziell inoffiziell ist, gerade WENN das original nicht public ist (diese Fassung wird aber gut aktualisiert) würde ich es nicht nutzen, aber ich habe wie gesagt meine ERfahrungen gemacht und verzichte einfach drauf

[HaWe]

bitte mal echten Code, keine Allgemeinplätze!
auch arbeite ich nicht mit std::thread sondern pthread !!! (Bitte immer genau lesen!)

den aktuellen Code findest du hier: https://www.roboternetz.de/community...l=1#post652711
(habe ich frisch geupdated)

[Ceos]

int pthread_kill(pthread_t thread, int sig); 

+ 

Signal        x86/ARM     Alpha/   MIPS   PARISC   Notes
                   most others   SPARC
       ─────────────────────────────────────────────────────────────────
       SIGKILL          9           9       9       9
       SIGSTOP         19          17      23      24

das ist gleichzusetzen mit dem was du vom OS aus machen kannst! Damit ist der Prozess 100% weg und kann neu gestartet werden. Dein Bedürftnis nach fertig compilierebarem Code kann ich nicht befriedigen, dafür ist mir die Bezahlung zu schlecht.

PS sigkill ist das signal der WAhl, was sigstop macht habe ich selbst so noch nie getestet, aber da es nciht Platformunabhängig ist würde ich es auch ncie in Betracht ziehen

[HaWe]

SIGKILL habe ich doch oben als Parameter für pthread_kill(tid, sig) selber schon genannt
https://www.roboternetz.de/community...l=1#post652792
- es ist der höchstmögliche, "stärkste" Wert für Linux - inwiefern soll dein Hinweis jetzt weiterhelfen?
(edit: SIGTERM oder SIGQUIT gingen auch, aber ich will ja für den Notfall die "stärkste" Methode, die mit der höchsten Wahrscheinlichkeit sofort wirkt).