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

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?

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

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.... :-k

Zitat:

---

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.... :-k

---

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)

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

Zitat:

---

Zitat von HaWe

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.... :-k

---

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

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?

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() ;)

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)

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)

Es gibt in dem Screenshot a.out und einen Eintrag unter a.out. Das eine ist der main thread und das zweite ist der worker thread.

ach so, worker ist der pthread.
aber trotzdem verstehe nicht, was da "gejoint" wird bzw. was damit gemeint ist.
joinen in meinem Verständnis heit, es läuft jetzt - statt wie bisher pseudosimultan getrennt - nunmehr unter einem gemeinsamen Dach in einem gemeinsamen (main) thread weiter.

Hier: Das zeigt es Graphisch

https://social.technet.microsoft.com...delegates.aspx

Der worker thread muss eben wieder sauber beendet werden und die Resourcen dem OS zurückgegeben werden. Nach dem join() ist dein Programm wieder single threaded.

das klingt aber nach einem "stoppen und aufräumen", nicht nach "beitreten"... :confused:

@HaWe schau bitte meinen Beitrag auf Seite 1 nochmal an, das hat sich beim tippen gerade überschnitten und ist auf Seite 1 letzter Beitrag untergegangen, da erkläre ich dir exemplarisch warum du "joinen" musst ... Threads könne nicht einfach so miteinander reden

"beitreten" bedeutet doch, dass etwas nach wie vor weiterläuft, nur jetzt gemeinsam, nicht mehr getrennt...
(hat sich überschnitten)

- - - Aktualisiert - - -

@Ceos:
ja, das hatte ich gelesen - aber nicht verstanden.
Mir geht um die Wortbedeutung von "join", und das heißt "verbinden, beitreten", nicht "beenden".
"stoppen und aufräumen" würde ich verstehen.

join bedeutet aber auch vereinigen ;)

https://dict.leo.org/englisch-deutsch/join

ja, aber vereinen bedeutet: es läuft weiter, gemeinsam unter 1 Dach.

wenn 1 thread jede Sekunde etwas ausgibt und unabhängig ein anderer thread etwas berechnet ,
und jetzt wird gejoint (vereint),
dann machen beide alles weiter, aber nicht mehr simultan nebeneinander sondern jetzt nacheinander (aneinandergehängt).

"join the army" bedeutet ja auch: der Army beitreten und mitmachen, und nicht aus ihr austreten oder (sofort) sein Leben beenden... ;)

Zitat:

---

Mir geht um die Wortbedeutung von "join", und das heißt "verbinden, beitreten", nicht "beenden".
"stoppen und aufräumen" würde ich verstehen.

---

Darum ja mein Beispiel mit dem Kollegen udn der Flex ... solange der Kollege am schleifen und schneiden ist und seinen Lärmschutz und Schutzbrille aufhat, kannst du winken, schrein, fuchteln, wedeln .... er bekommt nix mit!!!!

Du musst ihn erst auf die Schulter klopfen (join) um ihm dann zu sagen er kann Feierabend machen ... der Kollege muss sich dann aber SELBER darum kümmern aufzuräumen und nach Hause zu gehen!

Ein "kill" ist so als würdest du ihn einfach von jetzt auf gleich aus der Tür schmeißen und DU müsstest dann alles Aufräumen ... da es aber nicht dein Arbeitsplatz ist KANNST DU ES NICHT! Du kannst bestenfalls selber nach Hause gehen und vor dem verlassen noch alles anzünden und morgen von vorne anfangen.

ja, ok, trotzdem ist das, was er machen soll, ja nicht in den main thread kommen und weitermachen mt dem, was er bisher tut (join), sondern aufhören und aufräumen (stop_and_cleanup)

Und um hier nochmal zu erklären warum das so kompliziert sein muss:

Threads haben einen eigenen Kontext in dem sie arbeiten und in dem alle Daten als vertrauenswürdig erscheinen!
Ein Thread KANN THEORETISCH hingehen und Variablen in einem anderen Thread verändern wie es ihm beliebt ... ob der andere Thread damit klarkommt oder einfach ins leere greift, weil du die Flex auf einen anderen Platz gelegt hat ist fragwürdig und daher von den meisten Thread Bibliotheken verboten und resultiert zum Beispiel in Java in einer Exception wegen falschem Thread Zugriff!

Man kann sogenannte ATOMICS einsetzen, dabei werden Passagen des Programms innerhalb eines Threads für "nicht unterbrechbar" erklärt und niemand kann während dieser Sequenz irgendwelche Variablen verändern oder die Ausführung dieser Sequenz behindern/beenden

Man kann auch überall yield() oder sleep() einsetzen, wann immer man der Überzeugung ist, dass alle Variablen und auch der Zustand des Threads es erlauben die Kontrolle über das Programm an einen anderen Thread abzugeben, welcher dann nach belieben Variablen in dem wartenden Prozess zu verändern. Bei Microcontrollern REICHT DIESE METHODE VOLLKOMMEN AUS!!!

Bei Mehrkernsystemen kann es aber dazu kommen, dass das yield() ignoriert wird und der Thread weiterarbeitet, weil es mehr als einen echten Kern gibt! Also kann es sein, dass Thread A estwas in Thread B verändern will, der aber stur weiterarbeitet und du somit keinen Zugriff erhälst (laute Flex, eingeschränkes Gehör und Sicht) ... also musst du joinen/anklopfen ... und dann macht Thread B an einer der definierten Stellen (yield(), sleep(),...) eine ECHTE Pause und wartet dass du dein Join beendest und er weiter machen kann!

ACHTUNG WICHTIG falls du den Merhkernpart übersprungen hast weil er dich nicht trifft, ist es dennoch gute Praxis immer ein join/mutex/atomic zu nutzen um konsistente daten zwischen den Threads zu gewährleisten!

das Prinzip, was gemacht werden kann und muss, ist mir doch klar!
Es geht mir darum, dass der Befehl "join" heißt, obwohl das nichts mit "join=komm her+mach mit" zu tun hat , wenn man sagen will:
"stop jetzt und räum auf!"

Das wäre, wie wenn eine Kolonne im Straßenbau einem Arbeiter, der einsam seine Gräben schaufelt, sagt:
"Join here = schließ dich hier an"!
was bedeutet: "komm her und mach hier bei uns mit",
und es aber tatsächlich verstanden wird als: schmeiß den Spaten auf den Laster und geh nachhause!

Da kann doch was nicht stimmen!

Mhm ... mir fällt gerade auf dass ich die ganze "join" mit "invoke" verwechsle ... Sorry fürs irreführen!!!!

Join macht einfach aus zwei Threads wieder einen ... du rufst thread.join() in der main auf und die main wartet dann so lange bis dein Thread sich beendet hat und setzt dann die Main fort

Würdest du das nicht tun und der Main Prozess endet obwohl der Worker noch (sagen wir mal in eine Datei schreibt) würde der einfach abgewürgt und alle nicht gespeicherten Daten gehen verloren.

PS: da sieht man mal wieder was passiert wenn man Jahrelang nurnoch mit Controllern arbeitet und seit einer Weile kein echtes Multithreading mehr programmiert hat :D

Aber um das "wie beende ich den Thread" zu erklären kannst du dich gerne an meine anderen Ausführungen halten ... Threads haben einen eigenen Kontext und sehen nicht ob der andere gerade was arbeitet oder nicht. Du weist also auch nciht ob der andere verstanden hat was du von ihm willst, daher muss man sich erst synchronisieren! Oder feste Zeichen vereinbaren (eine Ampel mit Rot Grün für Arbeiten oder Feierabend ... in dem Sinne eine globale Variable)

ich mache ja nicht aus 2 threads einen.
ich lasse einen der beiden weiterlaufen wie bisher
- und sage einem anderen, er soll aufhören und aufräumen: Denn der macht ja nicht mit in dem anderen Thread, der übrig bleibt.

nochmal in einem Satz!

Du rufst in der main dein thread.join() auf und die Main wartet so lange bis der thread zum Ende gekommen ist! das macht man NUR DANN wenn man das ganze Programm sauber beenden möchte, oder sonst keine andere Möglichkeit hat zu überprüfen ob der Thread effektiv beendet ist oder nicht!

Du könntest auch eine "workerFinished" Variable global anlegen, im anfang der thread.loop() die Variable auf false setzen und als allerletzte Aktion diese Variable wieder auf true setzen! dann bauchst du kein join() sondern nur ein while(!workerFinished) sleep(1); Schleife

Wenn ein Thread auf einen anderen warten muss bis dieser beendet ist wäre es aber pure Zeitverschwendung jede Sekunde NUR um diese variable zu prüfen den anderen Thread zu unterbrechen (1 Kern System) also macht es mehr Sinn beide Thread durch ein join zu einem zu vereinen ... solange der thread nicht fertig ist kann die main doch soweiso ncihts sinnvolles machen!

verstehe ich nicht, was das, was du beschreibst, mit "join=mitmachen" zu tun hat, ich nenne es "geordnet stoppen".

Zitat:

---

ich nenne es "geordnet stoppen".

---

Das ist halt deine Meinung, ich sage dir nur was der Rest der Welt denkt.

Dein Wortverständnis ist wie ein Tellerrand und macnhmal sollte man darüber hinwegsehen um weiter zu kommen .. genau so wie ich häufiger detailliert die Beiträge lesen sollte um gleich zu erkennen dass es hier nur um das "koordinierte stoppen" geht

https://dict.leo.org/englisch-deutsch/join

Vielleicht gefallen dir die alternativen Übersetzungen besser

Jap, ich dachte, es müsste hinter "join" vom Wortverständnis her etwas anderes stecken als nur "geordnetes stoppen", aber es scheint wohl dass das ist nicht der Fall ist.

Wenn das also so ist und nach join nichts weiterläuft:
Dann überlege ich gerade, was man zu tun hat, wenn ein thread hängt ( _HEARTBEAT_ = false ),
z.B. der, der UART übeträgt...


edit,
vorige Idee kann nicht funktionieren über Semaphore, dann also nach
pthread_create(&tid, ...)

zum Beenden :
pthread_testcancel(tid)
pthread_cancel(tid)

oder mit Gewalt
pthread_kill(tid, SIGKILL); // in <signal.h>
pthread_join(tid);

und dann neu starten

DAS ist die Kunst des programmierens solche deadlocks einfach nicht zu machen

Zitat:

---

z.B. der, der UART übeträgt...

---

spröde einfache antwort: blocking read vermeiden!

du musst halt auch ein wenig mehr aufpassen was du machst wenn du threads verwendest ... schonmal mit serial.available() gearbeitet?! das blockiert nicht und sagt dir wieviele bytes im puffer sind!

es gibt KAUM eine schnittstelle bei der es unmöglich ist blocking calls zu vermeiden, alles nur eine frage des aufwandes

Zitat:

---

Zitat von Ceos

DAS ist die Kunst des programmierens solche deadlocks einfach nicht zu machen

spröde einfache antwort: blocking read vermeiden!

du musst halt auch ein wenig mehr aufpassen was du machst wenn du threads verwendest ... schonmal mit serial.available() gearbeitet?! das blockiert nicht und sagt dir wieviele bytes im puffer sind!

es gibt KAUM eine schnittstelle bei der es unmöglich ist blocking calls zu vermeiden, alles nur eine frage des aufwandes

---

das ist doch Unsinn, das kann ich nicht 100%ig vermeiden!
z.B., was ist wenn das UART-USB- Kabel abgeht oder doch wieder der kernel dazwischenfunkt und zu einem timeout führt (edit: wie vorher in der singlethread-Version)?
Oder der Arduino aus irgendeinem unbekannten Grund temporär den USB blockiert?
Genau dafür brauche ich nun eben diesen Plan B!

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!

Zitat:

---

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

Zitat:

---

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

Zitat:

---

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!

Zitat:

---

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)

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.

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.

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,

Zitat:

---

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.

Zitat:

---

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 :D

PS:

Zitat:

---

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

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.

Zitat:

---

wieder mal sehr theoretsch -

---

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

Zitat:

---

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

Code:

---

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

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)

Code:

---

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

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