- LiTime Speicher und Akkus         
Seite 3 von 10 ErsteErste 12345 ... LetzteLetzte
Ergebnis 21 bis 30 von 94

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

  1. #21
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    39
    Beiträge
    3.416
    Anzeige

    Praxistest und DIY Projekte
    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!
    Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
    nicht.

  2. #22
    HaWe
    Gast
    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!

  3. #23
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    39
    Beiträge
    3.416
    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

    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)
    Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
    nicht.

  4. #24
    HaWe
    Gast
    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.

  5. #25
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    39
    Beiträge
    3.416
    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.

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

  7. #27
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    39
    Beiträge
    3.416
    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
    Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
    nicht.

  8. #28
    HaWe
    Gast
    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)

  9. #29
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    39
    Beiträge
    3.416
    DAS ist die Kunst des programmierens solche deadlocks einfach nicht zu machen

    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
    Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
    nicht.

  10. #30
    HaWe
    Gast
    Zitat Zitat von Ceos Beitrag anzeigen
    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!

Seite 3 von 10 ErsteErste 12345 ... LetzteLetzte

Ähnliche Themen

  1. Antworten: 10
    Letzter Beitrag: 01.11.2017, 13:53
  2. Antworten: 2
    Letzter Beitrag: 15.06.2011, 22:18
  3. "Optimization" macht debuggen schwer
    Von yaro im Forum C - Programmierung (GCC u.a.)
    Antworten: 2
    Letzter Beitrag: 05.02.2010, 21:40
  4. "Soft-Reset?" und "Finger-Interrupt?"
    Von trapperjohn im Forum Asuro
    Antworten: 8
    Letzter Beitrag: 11.06.2008, 00:02
  5. ASM: was machen "swap" und "cbr" genau?
    Von RHS im Forum AVR Hardwarethemen
    Antworten: 3
    Letzter Beitrag: 18.08.2004, 18:16

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiFePO4 Speicher Test