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

Zitat:

---

Zitat von HaWe

wieso schreibst du jetzt was zu Windows?

---

Weil das "Multitasking" von Windows 3.11 nur Threads kannte und keine Tasks. Unix benutzt schon immer Tasks und wird sicher nie sein "Multitasking" auf so eine unsichere Umgebung wie Threads umstellen, POSIX hin oder her.

Zitat:

---

Aber lassen wir das mit der Historie und den Grundsatzdiskussionen:
pthread ist ANSI C99 Standard, pthread ist relativ einfach anzuwenden (sogar einfacher als std::thread finde ich), und es ist seit langem erprobt, bewährt und ohne Bugs.

---

Es geht nicht um Bugs im System, es geht um die, die Du programmierst. Führt ein Bug in einem deiner Threads zum Absturz oder überschreibt einer deiner Threads die Variablen eines anderen Threads, stürzt nicht nur der eine Thread sondern auch alle anderen ab. Dies ist der Nachteil, den man sich einhandelt, wenn man sich die Komplexität im Umgang mit Tasks sparen will. Und dies ist auch der Grund, warum Windows seit NT auch auf Tasks basiert (und damit erst wirklich brauchbar geworden ist).

Zitat:

---

Immerhin ist pthread zur Implementierung deutlich weniger komplex als Subprozesse, daher würde ich pthread in jedem Falle den Vorzug geben.

---

"There is no such thing as a free lunch"

MfG Klebwax

P.S.

Zitat:

---

- dennoch müssen hnterher noch Speicher und Pointer etc. aufgeräumt werden, z.B. existiert immer noch ein thread-Handle über die thread-ID, und auch die wird erst durch pthread_join gelöscht.
- auch wenn der Thread sich nicht selber beendet, sondern er über pthread_cancel beendet wurde, ist der Thread handle noch nicht geschlossen, auch das muss noch durch ein zusätzliches pthread_join erledigt werden.

---

Das alles und noch viel, auf das du noch kommen wirst, erledigt bei einer Task das Betriebssystem.

Zitat:

---

Zitat von Klebwax

Zum Schluß stellt man dann fest, daß man ein eigenes Betriebssystem programmiert hat, das aber längst auf dem System vorhanden ist. Das eigene ist auch nicht einfacher als das vorhandene, dafür ist es nur von einem selbst getestet und es fehlen hunderte Seiten man-Pages. Wer schreibt schon sowas zum eigenen Code? Wegen der Threadüberwachung ist es sogar langsamer als ein System, das auf Tasks basiert.

---

Deine Grundsatzdiskussionen helfen nicht wirklich weiter. In C aber ist immer schon vieles möglich, was zu Überschreiben von Speicherbereichen führt: In C muss nunmal der Programmierer aufpassen, was er tut, es ist von der Sprache her (fast) alles erlaubt, auch damit verbundene Fehler.
Ich sehe auch nicht, dass du hier eine ernsthafte, praktikable Alternative zu pthread anbieten kannst, die u.a. auch halbwegs Hobbyprogrammierer-tauglich ist (Prozesse und Subprozesse mit pipes etc sind es definitv NICHT!).
Also lassen wir jetzt bitte diese frustranen und sinnlosen Grundsatzdiskussionen ;)

Zitat:

---

Zitat von HaWe

Deine Grundsatzdiskussionen helfen nicht wirklich weiter. In C aber ist immer schon vieles möglich, was zu Überschreiben von Speicherbereichen führt:

---

Von einer Task in eine andere??

Zitat:

---

In C muss nunmal der Programmierer aufpassen, was er tut, es ist von der Sprache her (fast) alles erlaubt, auch damit verbundene Fehler.

---

Und das Multitasking sorgt dafür, daß es nicht jedesmal einen Reboot des Gesamtsystems gibt.

Ich will auch nichts anbieten, ich will dich nur dazu bringen, die Konsequenzen deiner Entscheidung für Threads zu realisieren. "einfacher" wäre mir als Begründung zu wenig.

Aber du hast recht, es ist genug gesagt, du hast nur noch nicht alles verstanden

MfG Klebwax

nein, ich denke du hast noch nicht alles verstanden, nämlich den Gesamtkontext und Sinn und Zweck der Anwendung, und POSIX pthread ist immerhin seit 20 Jahren eine etablierte ANSI C Standardlib.
Irgendwas schlechtreden ohne konstruktive Alternativen ist aber in jedem Falle eine ziemlich billige Attitüde.