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

[Ceos]

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)

[schorsch_76]

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.

[HaWe]

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.

[schorsch_76]

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.

[HaWe]

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

[Ceos]

@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

[HaWe]

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

[schorsch_76]

join bedeutet aber auch vereinigen

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

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