Thread (Informatik) - Versionsgeschichte

Luckywiki1234: /* growthexperiments-addlink-summary-summary:2|0|0 */

2025-04-23T20:29:53Z

Linkvorschlag-Funktion: 2 Links hinzugefügt.

← Nächstältere Version		Version vom 23. April 2025, 22:29 Uhr
Zeile 30:		Zeile 30:
	Ein ''[[Prozess (Informatik)\|Prozess]]'' bezeichnet den Ablauf eines [[Computerprogramm]]es auf einem oder mehreren [[Prozessor]](en). Einem Prozess sind ein Adressraum und weitere Betriebssystemmittel zugeordnet – insbesondere sind Prozesse gegeneinander abgeschirmt: Versucht ein Prozess, auf Adressen oder Betriebsmittel zuzugreifen, die ihm nicht zugeteilt wurden (und ggf. einem anderen Prozess gehören), so schlägt dies fehl und er wird vom Betriebssystem abgebrochen. Ein Prozess kann mehrere Threads oder – wenn bei dem Programmablauf keine Parallelverarbeitung vorgesehen ist – auch nur einen einzigen Thread beinhalten. Threads teilen sich innerhalb eines Prozesses Prozessoren, den Speicher und andere betriebssystemabhängige Ressourcen wie Dateien und Netzwerkverbindungen. Deswegen ist der Verwaltungsaufwand für Threads üblicherweise geringer als der für Prozesse. Ein wesentlicher Effizienzvorteil von Threads besteht zum einen darin, dass im Gegensatz zu Prozessen beim Threadwechsel kein vollständiger Wechsel des [[Prozesskontext]]es notwendig ist, da alle Threads einen gemeinsamen Teil des Prozesskontextes verwenden, zum anderen in der einfachen Kommunikation und schnellem Datenaustausch zwischen Threads.		Ein ''[[Prozess (Informatik)\|Prozess]]'' bezeichnet den Ablauf eines [[Computerprogramm]]es auf einem oder mehreren [[Prozessor]](en). Einem Prozess sind ein Adressraum und weitere Betriebssystemmittel zugeordnet – insbesondere sind Prozesse gegeneinander abgeschirmt: Versucht ein Prozess, auf Adressen oder Betriebsmittel zuzugreifen, die ihm nicht zugeteilt wurden (und ggf. einem anderen Prozess gehören), so schlägt dies fehl und er wird vom Betriebssystem abgebrochen. Ein Prozess kann mehrere Threads oder – wenn bei dem Programmablauf keine Parallelverarbeitung vorgesehen ist – auch nur einen einzigen Thread beinhalten. Threads teilen sich innerhalb eines Prozesses Prozessoren, den Speicher und andere betriebssystemabhängige Ressourcen wie Dateien und Netzwerkverbindungen. Deswegen ist der Verwaltungsaufwand für Threads üblicherweise geringer als der für Prozesse. Ein wesentlicher Effizienzvorteil von Threads besteht zum einen darin, dass im Gegensatz zu Prozessen beim Threadwechsel kein vollständiger Wechsel des [[Prozesskontext]]es notwendig ist, da alle Threads einen gemeinsamen Teil des Prozesskontextes verwenden, zum anderen in der einfachen Kommunikation und schnellem Datenaustausch zwischen Threads.

	Bereits in den 1980er Jahren gab es sogenannte [[Multitasking\|Multitask-Betriebssysteme]], da im Unterschied zu den joborientierten Systemen insbesondere in der damals so bezeichneten ''[[Prozessrechentechnik]]'' mehrere Aufgaben quasi parallel ausgeführt werden mussten. Damals hat sich der Begriff '''[[Task]]''' für eine Aufgabe aus Sicht des Betriebssystems eingebürgert, das ist ein Synonym zu Prozess. Der Begriff ''Task'' (deutsch: ''Aufgabe'') wird in der Softwarearchitektur aber auch unscharf allgemein für zusammenhängende Aufgaben benutzt, und insbesondere auch selten synonym für ''Thread'' eingesetzt.		Bereits in den 1980er Jahren gab es sogenannte [[Multitasking\|Multitask-Betriebssysteme]], da im Unterschied zu den joborientierten Systemen insbesondere in der damals so bezeichneten ''[[Prozessrechentechnik]]'' mehrere Aufgaben quasi parallel ausgeführt werden mussten. Damals hat sich der Begriff '''[[Task]]''' für eine Aufgabe aus Sicht des Betriebssystems eingebürgert, das ist ein Synonym zu Prozess. Der Begriff ''Task'' (deutsch: ''Aufgabe'') wird in der [[Softwarearchitektur]] aber auch unscharf allgemein für zusammenhängende Aufgaben benutzt, und insbesondere auch selten synonym für ''Thread'' eingesetzt.

	Ein Thread ist wörtlich ein einzelner Ausführungsfaden eines Programms, der Begriff Thread wird aber auf den Ausführungsstrang aus Sicht des Betriebssystems eingesetzt (Kernelthread). In einer Anwendersoftware kann dieser Ausführungsstrang durch geeignete Programmierung nochmals in unabhängige Einzelstränge unterteilt werden. Im englischen Sprachraum hat sich für einen einzelnen solchen Ausführungsstrang der Anwendersoftware der Begriff '''[[User-Thread]]''' (bei Microsoft ''Fiber'', deutsch: ''Faser'') eingebürgert. Bei User Threads ist allein die Anwendersoftware für die Verwaltung ihrer Ausführungsstränge zuständig.		Ein Thread ist wörtlich ein einzelner Ausführungsfaden eines Programms, der Begriff Thread wird aber auf den Ausführungsstrang aus Sicht des Betriebssystems eingesetzt (Kernelthread). In einer Anwendersoftware kann dieser Ausführungsstrang durch geeignete Programmierung nochmals in unabhängige Einzelstränge unterteilt werden. Im englischen Sprachraum hat sich für einen einzelnen solchen Ausführungsstrang der Anwendersoftware der Begriff '''[[User-Thread]]''' (bei Microsoft ''Fiber'', deutsch: ''Faser'') eingebürgert. Bei User Threads ist allein die Anwendersoftware für die Verwaltung ihrer Ausführungsstränge zuständig.
Zeile 114:		Zeile 114:
	Die .NET-Runtime unterscheidet außerdem zwischen Vordergrundthreads und Hintergrundthreads. Ein Thread wird zum Hintergrundthread durch Setzen der Eigenschaft ''Background'' auf ''true''. Ein Prozess wird beendet, wenn der letzte Vordergrundthread beendet ist. Alle dann noch laufenden Hintergrundthreads werden automatisch beendet. Threadpool Threads werden als Hintergrundthread gestartet.		Die .NET-Runtime unterscheidet außerdem zwischen Vordergrundthreads und Hintergrundthreads. Ein Thread wird zum Hintergrundthread durch Setzen der Eigenschaft ''Background'' auf ''true''. Ein Prozess wird beendet, wenn der letzte Vordergrundthread beendet ist. Alle dann noch laufenden Hintergrundthreads werden automatisch beendet. Threadpool Threads werden als Hintergrundthread gestartet.

	Einen eigenständigen Thread startet man über eine neue Instanz einer Thread-Klasse, der im Konstruktor eine Rückruffunktion ([[Methodenzeiger\|Delegate]]) übergeben wird. Der Thread wird dann über die Instanzmethode ''Start()'' gestartet. Der Thread wird beendet, wenn die Rückruffunktion die Kontrolle an den Aufrufer zurückgibt.		Einen eigenständigen Thread startet man über eine neue Instanz einer Thread-Klasse, der im Konstruktor eine [[Rückruffunktion]] ([[Methodenzeiger\|Delegate]]) übergeben wird. Der Thread wird dann über die Instanzmethode ''Start()'' gestartet. Der Thread wird beendet, wenn die Rückruffunktion die Kontrolle an den Aufrufer zurückgibt.

	Alternativ ist für kurze Hintergrundverarbeitung der ThreadPool der .NET Runtime nutzbar. Dieser hält eine gewisse Anzahl von Threads vor, die über ''ThreadPool.QueueUserWorkItem()'' zur Verarbeitung genutzt werden können. Nach Rückkehr der übergebenen Rückruffunktion wird der Thread dann nicht durch das Betriebssystem zerstört, sondern für die spätere Verwendung zwischengespeichert. Vorteil dieser Klasse ist die optimierte, beschränkte Nutzung des zugrunde liegenden Betriebsmittels.		Alternativ ist für kurze Hintergrundverarbeitung der ThreadPool der .NET Runtime nutzbar. Dieser hält eine gewisse Anzahl von Threads vor, die über ''ThreadPool.QueueUserWorkItem()'' zur Verarbeitung genutzt werden können. Nach Rückkehr der übergebenen Rückruffunktion wird der Thread dann nicht durch das Betriebssystem zerstört, sondern für die spätere Verwendung zwischengespeichert. Vorteil dieser Klasse ist die optimierte, beschränkte Nutzung des zugrunde liegenden Betriebsmittels.

T. Wirbitzki: Die letzte Textänderung von 185.116.38.131 wurde verworfen und die Version 232151847 von T. Wirbitzki wiederhergestellt. Verschlechterung liegt vor: Erstens darf ein Link auf ein Zustandsdiagramm nicht als Aktivitätsdiagramm bezeichnet werden. Zweitens gehen die folgenden Sätze wieder auf Zustandsdiagramme ein, nicht auf Aktivitätsdiagramme, das irritiert.

2023-07-20T20:32:15Z

Die letzte Textänderung von 185.116.38.131 wurde verworfen und die Version 232151847 von T. Wirbitzki wiederhergestellt. Verschlechterung liegt vor: Erstens darf ein Link auf ein Zustandsdiagramm nicht als Aktivitätsdiagramm bezeichnet werden. Zweitens gehen die folgenden Sätze wieder auf Zustandsdiagramme ein, nicht auf Aktivitätsdiagramme, das irritiert.

← Nächstältere Version		Version vom 20. Juli 2023, 22:32 Uhr
Zeile 190:		Zeile 190:

	== Threaddarstellung in UML ==		== Threaddarstellung in UML ==
	Parallele Prozesse werden in der [[Unified Modeling Language]] (UML) oft mit [[Zustandsdiagramm (UML)\|~~Aktivitätsdiagrammen~~ ~~unter Verwendung paraller Regionen~~]] dargestellt. In einem Zustandsdiagramm sind innerhalb eines Zustandes interne parallele Teil-Zustandsdiagramme darstellbar. Alle Zustandsdiagramme des Gesamtsystems werden quasiparallel abgearbeitet. Die Quasiparallelität wird dadurch erreicht, dass jeder Zustandsübergang sehr kurz ist (in der Praxis wenige Mikrosekunden bis Millisekunden) und daher das Nacheinander der Abarbeitung als parallel erscheint. Der Übergang von einem Zustand in einen anderen wird typischerweise mit einem [[Ereignis (Programmierung)\|Ereignis (Event)]] ausgelöst, das zuvor in die sogenannte Eventqueue eingeschrieben wurde. Dieser Übergang aufgrund eines Ereignisses ist nach der oben angegebenen Definition ein Userthread. Prinzipiell ist die damit realisierte Parallelität mit nur einem einzigen Betriebssystem-Thread erreichbar.		Parallele Prozesse werden in der [[Unified Modeling Language]] (UML) oft mit [[Zustandsdiagramm (UML)\|Zustandsdiagrammen (Statecharts)]] dargestellt. In einem Zustandsdiagramm sind innerhalb eines Zustandes interne parallele Teil-Zustandsdiagramme darstellbar. Alle Zustandsdiagramme des Gesamtsystems werden quasiparallel abgearbeitet. Die Quasiparallelität wird dadurch erreicht, dass jeder Zustandsübergang sehr kurz ist (in der Praxis wenige Mikrosekunden bis Millisekunden) und daher das Nacheinander der Abarbeitung als parallel erscheint. Der Übergang von einem Zustand in einen anderen wird typischerweise mit einem [[Ereignis (Programmierung)\|Ereignis (Event)]] ausgelöst, das zuvor in die sogenannte Eventqueue eingeschrieben wurde. Dieser Übergang aufgrund eines Ereignisses ist nach der oben angegebenen Definition ein Userthread. Prinzipiell ist die damit realisierte Parallelität mit nur einem einzigen Betriebssystem-Thread erreichbar.

	Setzt man UML für schnelle Systeme ein, dann spielt die Frage einer zeitlichen [[Priorität\|Priorisierung]] eine Rolle. Können Zustandsübergänge längere Zeit in Anspruch nehmen oder es soll in einem Übergang noch zusätzlich auf Bedingungen gewartet werden (passiert bereits bei einem einfachen Lesen oder Schreiben auf eine Datei), dann muss eine Parallelität mit Threads realisiert werden. Aus diesem Grunde muss man die Zustandsdiagramm-Abarbeitung mehreren gegebenenfalls unterschiedlich prioren Threads des Systems zuordnen können. Das UML-Werkzeug [[Rational Rhapsody\|Rhapsody]] kennt dazu den Begriff der ''aktiven Klasse''. Jede aktive Klasse ist einem eigenen Thread zugeordnet.		Setzt man UML für schnelle Systeme ein, dann spielt die Frage einer zeitlichen [[Priorität\|Priorisierung]] eine Rolle. Können Zustandsübergänge längere Zeit in Anspruch nehmen oder es soll in einem Übergang noch zusätzlich auf Bedingungen gewartet werden (passiert bereits bei einem einfachen Lesen oder Schreiben auf eine Datei), dann muss eine Parallelität mit Threads realisiert werden. Aus diesem Grunde muss man die Zustandsdiagramm-Abarbeitung mehreren gegebenenfalls unterschiedlich prioren Threads des Systems zuordnen können. Das UML-Werkzeug [[Rational Rhapsody\|Rhapsody]] kennt dazu den Begriff der ''aktiven Klasse''. Jede aktive Klasse ist einem eigenen Thread zugeordnet.

185.116.38.131: /* Threaddarstellung in UML */ s.a.: https://www.sparxsystems.eu/resources/project-development-with-uml-and-ea/activity-diagram, Vergleiche auch https://de.wikipedia.org/wiki/Zustandsdiagramm_(UML),

2023-07-20T18:43:14Z

Threaddarstellung in UML: s.a.: https://www.sparxsystems.eu/resources/project-development-with-uml-and-ea/activity-diagram, Vergleiche auch https://de.wikipedia.org/wiki/Zustandsdiagramm_(UML),

← Nächstältere Version		Version vom 20. Juli 2023, 20:43 Uhr
Zeile 190:		Zeile 190:

	== Threaddarstellung in UML ==		== Threaddarstellung in UML ==
	Parallele Prozesse werden in der [[Unified Modeling Language]] (UML) oft mit [[Zustandsdiagramm (UML)\|~~Zustandsdiagrammen~~ ~~(Statecharts)~~]] dargestellt. In einem Zustandsdiagramm sind innerhalb eines Zustandes interne parallele Teil-Zustandsdiagramme darstellbar. Alle Zustandsdiagramme des Gesamtsystems werden quasiparallel abgearbeitet. Die Quasiparallelität wird dadurch erreicht, dass jeder Zustandsübergang sehr kurz ist (in der Praxis wenige Mikrosekunden bis Millisekunden) und daher das Nacheinander der Abarbeitung als parallel erscheint. Der Übergang von einem Zustand in einen anderen wird typischerweise mit einem [[Ereignis (Programmierung)\|Ereignis (Event)]] ausgelöst, das zuvor in die sogenannte Eventqueue eingeschrieben wurde. Dieser Übergang aufgrund eines Ereignisses ist nach der oben angegebenen Definition ein Userthread. Prinzipiell ist die damit realisierte Parallelität mit nur einem einzigen Betriebssystem-Thread erreichbar.		Parallele Prozesse werden in der [[Unified Modeling Language]] (UML) oft mit [[Zustandsdiagramm (UML)\|Aktivitätsdiagrammen unter Verwendung paraller Regionen]] dargestellt. In einem Zustandsdiagramm sind innerhalb eines Zustandes interne parallele Teil-Zustandsdiagramme darstellbar. Alle Zustandsdiagramme des Gesamtsystems werden quasiparallel abgearbeitet. Die Quasiparallelität wird dadurch erreicht, dass jeder Zustandsübergang sehr kurz ist (in der Praxis wenige Mikrosekunden bis Millisekunden) und daher das Nacheinander der Abarbeitung als parallel erscheint. Der Übergang von einem Zustand in einen anderen wird typischerweise mit einem [[Ereignis (Programmierung)\|Ereignis (Event)]] ausgelöst, das zuvor in die sogenannte Eventqueue eingeschrieben wurde. Dieser Übergang aufgrund eines Ereignisses ist nach der oben angegebenen Definition ein Userthread. Prinzipiell ist die damit realisierte Parallelität mit nur einem einzigen Betriebssystem-Thread erreichbar.

	Setzt man UML für schnelle Systeme ein, dann spielt die Frage einer zeitlichen [[Priorität\|Priorisierung]] eine Rolle. Können Zustandsübergänge längere Zeit in Anspruch nehmen oder es soll in einem Übergang noch zusätzlich auf Bedingungen gewartet werden (passiert bereits bei einem einfachen Lesen oder Schreiben auf eine Datei), dann muss eine Parallelität mit Threads realisiert werden. Aus diesem Grunde muss man die Zustandsdiagramm-Abarbeitung mehreren gegebenenfalls unterschiedlich prioren Threads des Systems zuordnen können. Das UML-Werkzeug [[Rational Rhapsody\|Rhapsody]] kennt dazu den Begriff der ''aktiven Klasse''. Jede aktive Klasse ist einem eigenen Thread zugeordnet.		Setzt man UML für schnelle Systeme ein, dann spielt die Frage einer zeitlichen [[Priorität\|Priorisierung]] eine Rolle. Können Zustandsübergänge längere Zeit in Anspruch nehmen oder es soll in einem Übergang noch zusätzlich auf Bedingungen gewartet werden (passiert bereits bei einem einfachen Lesen oder Schreiben auf eine Datei), dann muss eine Parallelität mit Threads realisiert werden. Aus diesem Grunde muss man die Zustandsdiagramm-Abarbeitung mehreren gegebenenfalls unterschiedlich prioren Threads des Systems zuordnen können. Das UML-Werkzeug [[Rational Rhapsody\|Rhapsody]] kennt dazu den Begriff der ''aktiven Klasse''. Jede aktive Klasse ist einem eigenen Thread zugeordnet.

T. Wirbitzki: lk llnl.gov

2023-03-24T21:27:50Z

lk llnl.gov

← Nächstältere Version		Version vom 24. März 2023, 23:27 Uhr
Zeile 279:		Zeile 279:
	* [http://www.kegel.com/c10k.html The C10K problem] (englisch)		* [http://www.kegel.com/c10k.html The C10K problem] (englisch)
	* [http://www.jetbyte.com/portfolio-showarticle.asp?articleId=38&catId=1&subcatId=2 Business logic processing in a socket server – thread pools] (englisch)		* [http://www.jetbyte.com/portfolio-showarticle.asp?articleId=38&catId=1&subcatId=2 Business logic processing in a socket server – thread pools] (englisch)
	* [https://~~computing~~.llnl.gov/~~tutorials/pthreads~~/ Einführung in Pthreads mit C] (englisch~~) (Seite nicht mehr vorhanden~~)		* [https://hpc-tutorials.llnl.gov/posix/ Einführung in Pthreads mit C] (englisch)
	* {{Internetquelle		* {{Internetquelle
	\|autor=Joseph Albahari		\|autor=Joseph Albahari

95.70.234.230: /* Weblinks */

2023-03-12T18:44:22Z

Weblinks

← Nächstältere Version		Version vom 12. März 2023, 20:44 Uhr
Zeile 279:		Zeile 279:
	* [http://www.kegel.com/c10k.html The C10K problem] (englisch)		* [http://www.kegel.com/c10k.html The C10K problem] (englisch)
	* [http://www.jetbyte.com/portfolio-showarticle.asp?articleId=38&catId=1&subcatId=2 Business logic processing in a socket server – thread pools] (englisch)		* [http://www.jetbyte.com/portfolio-showarticle.asp?articleId=38&catId=1&subcatId=2 Business logic processing in a socket server – thread pools] (englisch)
	* [https://computing.llnl.gov/tutorials/pthreads/ Einführung in Pthreads mit C] (englisch)		* [https://computing.llnl.gov/tutorials/pthreads/ Einführung in Pthreads mit C] (englisch) (Seite nicht mehr vorhanden)
	* {{Internetquelle		* {{Internetquelle
	\|autor=Joseph Albahari		\|autor=Joseph Albahari

Unoli: Begriff ausgetauscht; alten Begriff in Klammer

2022-09-06T23:04:56Z

Begriff ausgetauscht; alten Begriff in Klammer

← Nächstältere Version		Version vom 7. September 2022, 01:04 Uhr
Zeile 16:		Zeile 16:

	Threads innerhalb des gleichen Prozesses können verschiedenen Prozessoren zugeordnet sein. Jeder Thread besitzt einen eigenen sogenannten Threadkontext:		Threads innerhalb des gleichen Prozesses können verschiedenen Prozessoren zugeordnet sein. Jeder Thread besitzt einen eigenen sogenannten Threadkontext:
	* unabhängiger Registersatz inkl. Instruction Pointer,		* unabhängiger Registersatz inkl. Befehlszeiger (Instruction Pointer),
	* einen eigenen [[Stapelspeicher\|Stapel]] (Stack), jedoch meist im gemeinsamen Prozess-Adressraum.		* einen eigenen [[Stapelspeicher\|Stapel]] (Stack), jedoch meist im gemeinsamen Prozess-Adressraum.
	* Als Besonderheit kann es Betriebsmittel geben, die nur von dem erzeugenden Thread benutzt werden können oder dürfen (Beispiel: [[Thread-local storage]], Window-Handle).		* Als Besonderheit kann es Betriebsmittel geben, die nur von dem erzeugenden Thread benutzt werden können oder dürfen (Beispiel: [[Thread-local storage]], Window-Handle).

Filzstift: /* .NET */BKL-fix, replaced: .NET → .NET mit AWB

2022-05-31T06:09:56Z

.NET: BKL-fix, replaced: .NET → .NET mit AWB

← Nächstältere Version		Version vom 31. Mai 2022, 08:09 Uhr
Zeile 106:		Zeile 106:

	=== .NET ===		=== .NET ===
	[[.NET]] unterstützt von Haus aus Threadprogrammierung. Realisiert wird dies durch die Klassen im Namensraum ''System.Threading''.		[[.NET (Oberbegriff)\|.NET]] unterstützt von Haus aus Threadprogrammierung. Realisiert wird dies durch die Klassen im Namensraum ''System.Threading''.

	Zusätzlich zu den oben genannten Konstrukten Prozess und Thread gibt es dort noch das Konzept einer Anwendungsdomäne (''AppDomain''). Ein Prozess kann dabei mehrere Anwendungsdomänen enthalten, diese werden von der Runtime isoliert („logischer Prozess“), eine vom [[.Net-Framework]] bereitgestellte Ressource ist an die erzeugende Anwendungsdomäne gebunden. Betriebsmittel des unterliegenden Betriebssystems (auch Kernelthreads!) sind aber nicht an diese logischen Prozessgrenzen gebunden.		Zusätzlich zu den oben genannten Konstrukten Prozess und Thread gibt es dort noch das Konzept einer Anwendungsdomäne (''AppDomain''). Ein Prozess kann dabei mehrere Anwendungsdomänen enthalten, diese werden von der Runtime isoliert („logischer Prozess“), eine vom [[.Net-Framework]] bereitgestellte Ressource ist an die erzeugende Anwendungsdomäne gebunden. Betriebsmittel des unterliegenden Betriebssystems (auch Kernelthreads!) sind aber nicht an diese logischen Prozessgrenzen gebunden.

Basotxerri: /* Threads aus Sicht des Betriebssystems */

2022-04-12T07:23:35Z

Threads aus Sicht des Betriebssystems

← Nächstältere Version		Version vom 12. April 2022, 09:23 Uhr
Zeile 9:		Zeile 9:
	== Threads aus Sicht des Betriebssystems ==		== Threads aus Sicht des Betriebssystems ==
	[[Datei:Threads (Informatik).png\|mini\|Mehrere Kernelthreads in einem Prozess (Task)]]		[[Datei:Threads (Informatik).png\|mini\|Mehrere Kernelthreads in einem Prozess (Task)]]
	Ein (Kernel-)Thread ist ein sequentieller Abarbeitungslauf innerhalb eines [[Prozess (Informatik)\|Prozesses]] und teilt sich mit den anderen vorhandenen Threads ([[~~multithreading~~]]) des zugehörigen Prozesses eine Reihe von [[Betriebsmittel (Informatik)\|Betriebsmitteln]]:		Ein (Kernel-)Thread ist ein sequentieller Abarbeitungslauf innerhalb eines [[Prozess (Informatik)\|Prozesses]] und teilt sich mit den anderen vorhandenen Threads ([[Multithreading]]) des zugehörigen Prozesses eine Reihe von [[Betriebsmittel (Informatik)\|Betriebsmitteln]]:
	* das [[Codesegment]],		* das [[Codesegment]],
	* das [[Datensegment]],		* das [[Datensegment]],

Aka: /* Literatur */ Dateigröße angepasst

2021-11-07T11:15:11Z

Literatur: Dateigröße angepasst

← Nächstältere Version		Version vom 7. November 2021, 13:15 Uhr
Zeile 248:		Zeile 248:
	\|Originaltitel=Modern Operating Systems		\|Originaltitel=Modern Operating Systems
	\|Originalsprache=en}}		\|Originalsprache=en}}
	* Edward A. Lee: ''The Problem with Threads''. Technical Report, University of California at Berkeley, [http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf berkeley.edu] (PDF)		* Edward A. Lee: ''The Problem with Threads''. Technical Report, University of California at Berkeley, [http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf berkeley.edu] (PDF; 199 kB)
	* Clay Breshears: ''The Art of Concurrency''. O’Reilly, ISBN 978-0-596-52153-0.		* Clay Breshears: ''The Art of Concurrency''. O’Reilly, ISBN 978-0-596-52153-0.
	* Dietrich Boles: [http://www.java-hamster-modell.de/eBooks/hamster3.pdf ''Parallele Programmierung spielend gelernt mit dem Java-Hamster-Modell – Programmierung mit Java-Threads''.] (PDF; 5,1 MB) Vieweg+Teubner-Verlag, 2008, ISBN 978-3-8351-0229-3.		* Dietrich Boles: [http://www.java-hamster-modell.de/eBooks/hamster3.pdf ''Parallele Programmierung spielend gelernt mit dem Java-Hamster-Modell – Programmierung mit Java-Threads''.] (PDF; 4,1 MB) Vieweg+Teubner-Verlag, 2008, ISBN 978-3-8351-0229-3.
	* {{Literatur		* {{Literatur
	\|Autor=James H. Anderson, Yong-Jik Kim, Ted Herman		\|Autor=James H. Anderson, Yong-Jik Kim, Ted Herman

Trustable: form

2021-08-07T22:24:43Z

form

← Nächstältere Version		Version vom 8. August 2021, 00:24 Uhr
Zeile 25:		Zeile 25:
	Jeder „Programmfaden“ ist für die Ausführung einer bestimmten Aufgabe verantwortlich. Die Ausführungsstränge der Programmfunktionen können damit in überschaubare Einheiten aufgeteilt werden sowie umfangreiche Aufgaben auf mehrere Prozessorkerne verteilt werden.		Jeder „Programmfaden“ ist für die Ausführung einer bestimmten Aufgabe verantwortlich. Die Ausführungsstränge der Programmfunktionen können damit in überschaubare Einheiten aufgeteilt werden sowie umfangreiche Aufgaben auf mehrere Prozessorkerne verteilt werden.

	Bei den meisten Betriebssystemen kann ein Thread neben den Zuständen ''aktiv'' (~~engl.~~ running), ''bereit'' (~~engl.~~ ready) und ''blockiert'' (~~engl.~~ waiting) auch einen Zustand ''inaktiv'' annehmen. Im Zustand ‚rechnend‘ (=aktiv =running) findet die Ausführung von Befehlen auf der [[Prozessor\|CPU]] statt, bei ‚rechenbereit‘ (=bereit =ready) ist der Thread gestoppt, um einen anderen Thread rechnen zu lassen und bei ‚blockiert‘ (=waiting) wartet der Thread auf ein Ereignis (meist dass ein Betriebssystem-Dienst fertig/durchgeführt wurde). Ein Thread im Zustand ‚inaktiv‘ wird meist gerade vom Betriebssystem neu eingerichtet oder hat fertiggerechnet und kann vom Betriebssystem nun aus der Threadliste entfernt oder anderweitig wiederverwendet werden.		Bei den meisten Betriebssystemen kann ein Thread neben den Zuständen ''aktiv'' (englisch running), ''bereit'' (englisch ready) und ''blockiert'' (englisch waiting) auch einen Zustand ''inaktiv'' annehmen. Im Zustand ‚rechnend‘ (=aktiv =running) findet die Ausführung von Befehlen auf der [[Prozessor\|CPU]] statt, bei ‚rechenbereit‘ (=bereit =ready) ist der Thread gestoppt, um einen anderen Thread rechnen zu lassen und bei ‚blockiert‘ (=waiting) wartet der Thread auf ein Ereignis (meist dass ein Betriebssystem-Dienst fertig/durchgeführt wurde). Ein Thread im Zustand ‚inaktiv‘ wird meist gerade vom Betriebssystem neu eingerichtet oder hat fertiggerechnet und kann vom Betriebssystem nun aus der Threadliste entfernt oder anderweitig wiederverwendet werden.

	== Bedeutungsunterschied (Kernel-)Thread gegenüber Prozess, Task und User Thread ==		== Bedeutungsunterschied (Kernel-)Thread gegenüber Prozess, Task und User Thread ==
Zeile 32:		Zeile 32:
	Bereits in den 1980er Jahren gab es sogenannte [[Multitasking\|Multitask-Betriebssysteme]], da im Unterschied zu den joborientierten Systemen insbesondere in der damals so bezeichneten ''[[Prozessrechentechnik]]'' mehrere Aufgaben quasi parallel ausgeführt werden mussten. Damals hat sich der Begriff '''[[Task]]''' für eine Aufgabe aus Sicht des Betriebssystems eingebürgert, das ist ein Synonym zu Prozess. Der Begriff ''Task'' (deutsch: ''Aufgabe'') wird in der Softwarearchitektur aber auch unscharf allgemein für zusammenhängende Aufgaben benutzt, und insbesondere auch selten synonym für ''Thread'' eingesetzt.		Bereits in den 1980er Jahren gab es sogenannte [[Multitasking\|Multitask-Betriebssysteme]], da im Unterschied zu den joborientierten Systemen insbesondere in der damals so bezeichneten ''[[Prozessrechentechnik]]'' mehrere Aufgaben quasi parallel ausgeführt werden mussten. Damals hat sich der Begriff '''[[Task]]''' für eine Aufgabe aus Sicht des Betriebssystems eingebürgert, das ist ein Synonym zu Prozess. Der Begriff ''Task'' (deutsch: ''Aufgabe'') wird in der Softwarearchitektur aber auch unscharf allgemein für zusammenhängende Aufgaben benutzt, und insbesondere auch selten synonym für ''Thread'' eingesetzt.

	Ein Thread ist wörtlich ein einzelner Ausführungsfaden eines Programms, der Begriff Thread wird aber auf den Ausführungsstrang aus Sicht des Betriebssystems eingesetzt (Kernelthread). In einer Anwendersoftware kann dieser Ausführungsstrang durch geeignete Programmierung nochmals in unabhängige Einzelstränge unterteilt werden. Im englischen Sprachraum hat sich für einen einzelnen solchen Ausführungsstrang der Anwendersoftware der Begriff '''[[User Thread]]''' (bei Microsoft ''Fiber'', deutsch: ''Faser'') eingebürgert. Bei User Threads ist allein die Anwendersoftware für die Verwaltung ihrer Ausführungsstränge zuständig.		Ein Thread ist wörtlich ein einzelner Ausführungsfaden eines Programms, der Begriff Thread wird aber auf den Ausführungsstrang aus Sicht des Betriebssystems eingesetzt (Kernelthread). In einer Anwendersoftware kann dieser Ausführungsstrang durch geeignete Programmierung nochmals in unabhängige Einzelstränge unterteilt werden. Im englischen Sprachraum hat sich für einen einzelnen solchen Ausführungsstrang der Anwendersoftware der Begriff '''[[User-Thread]]''' (bei Microsoft ''Fiber'', deutsch: ''Faser'') eingebürgert. Bei User Threads ist allein die Anwendersoftware für die Verwaltung ihrer Ausführungsstränge zuständig.

	=== Beispiele ===		=== Beispiele ===
Zeile 108:		Zeile 108:
	[[.NET]] unterstützt von Haus aus Threadprogrammierung. Realisiert wird dies durch die Klassen im Namensraum ''System.Threading''.		[[.NET]] unterstützt von Haus aus Threadprogrammierung. Realisiert wird dies durch die Klassen im Namensraum ''System.Threading''.

	Zusätzlich zu den oben genannten Konstrukten Prozess und Thread gibt es dort noch das Konzept einer Anwendungsdomäne (''AppDomain''). Ein Prozess kann dabei mehrere Anwendungsdomänen enthalten, diese werden von der Runtime isoliert („logischer Prozess“), eine vom .~~NET~~ Framework bereitgestellte Ressource ist an die erzeugende Anwendungsdomäne gebunden. Betriebsmittel des unterliegenden Betriebssystems (auch Kernelthreads!) sind aber nicht an diese logischen Prozessgrenzen gebunden.		Zusätzlich zu den oben genannten Konstrukten Prozess und Thread gibt es dort noch das Konzept einer Anwendungsdomäne (''AppDomain''). Ein Prozess kann dabei mehrere Anwendungsdomänen enthalten, diese werden von der Runtime isoliert („logischer Prozess“), eine vom [[.Net-Framework]] bereitgestellte Ressource ist an die erzeugende Anwendungsdomäne gebunden. Betriebsmittel des unterliegenden Betriebssystems (auch Kernelthreads!) sind aber nicht an diese logischen Prozessgrenzen gebunden.

	Auch bietet die .NET-Runtime einen von der Runtime verwalteten Threadpool, der durch diese zur Verarbeitung von asynchronen Ereignissen und Ein-/Ausgabeoperationen verwendet wird.		Auch bietet die .NET-Runtime einen von der Runtime verwalteten Threadpool, der durch diese zur Verarbeitung von asynchronen Ereignissen und Ein-/Ausgabeoperationen verwendet wird.
Zeile 120:		Zeile 120:
	Eine externe Steuerung der Threads ist möglich (''Abort()'', ''Suspend()'', ''Resume()''), kann aber zu unvorhersehbaren Ereignissen wie [[Deadlock (Informatik)\|''deadlocks'']] oder Abbrüchen der Anwendungsdomäne führen. Deshalb sind Suspend und Resume in neueren Versionen von .NET als obsolet markiert.		Eine externe Steuerung der Threads ist möglich (''Abort()'', ''Suspend()'', ''Resume()''), kann aber zu unvorhersehbaren Ereignissen wie [[Deadlock (Informatik)\|''deadlocks'']] oder Abbrüchen der Anwendungsdomäne führen. Deshalb sind Suspend und Resume in neueren Versionen von .NET als obsolet markiert.

	Die Synchronisation von Threads erfolgt durch ein ''WaitHandle''. Genutzt wird dieser meistens über die Klasse ''Monitor'' die einen durch jedes .NET-Objekt zur Verfügung gestellten [[Mutex]] nutzt. In C# kann dazu das lock(object){ Anweisung; } Konstrukt genutzt werden. Viele Klassen des .~~NET~~-Framework existieren zusätzlich in einer Threadsicheren Variante die über eine statische Methode ''Synchronized()'' erstellt werden kann.		Die Synchronisation von Threads erfolgt durch ein ''WaitHandle''. Genutzt wird dieser meistens über die Klasse ''Monitor'' die einen durch jedes .NET-Objekt zur Verfügung gestellten [[Mutex]] nutzt. In C# kann dazu das lock(object){ Anweisung; } Konstrukt genutzt werden. Viele Klassen des .Net-Framework existieren zusätzlich in einer Threadsicheren Variante die über eine statische Methode ''Synchronized()'' erstellt werden kann.

	=== Unix/Linux ===		=== Unix/Linux ===
Zeile 214:		Zeile 214:

	== Siehe auch ==		== Siehe auch ==
	* [[Hyper-Threading]], [[Multithreading]], [[User Thread]]		* [[Hyper-Threading]], [[Multithreading]], [[User-Thread]]
	<!--* [[Konflikt]]-->		<!--* [[Konflikt]]-->
	* [[Kritischer Abschnitt]]		* [[Kritischer Abschnitt]]