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.
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!
Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
nicht.
verstehe ich nicht, was das, was du beschreibst, mit "join=mitmachen" zu tun hat, ich nenne es "geordnet stoppen".
Das ist halt deine Meinung, ich sage dir nur was der Rest der Welt denkt.ich nenne es "geordnet stoppen".
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
Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
nicht.
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
Geändert von HaWe (14.06.2019 um 12:08 Uhr)
DAS ist die Kunst des programmierens solche deadlocks einfach nicht zu machen
spröde einfache antwort: blocking read vermeiden!z.B. der, der UART übeträgt...
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
Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
nicht.
das ist doch Unsinn, das kann ich nicht 100%ig vermeiden!Zitat von Ceos
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!
Berechtigungen
Zitieren
Lesezeichen