[Vienna-pm] Fragen zu Threads

[Bernd Petrovitsch]

On Mon, 2005-04-04 at 08:32 +0200, LAUN Wolfgang wrote:
> > -----Original Message-----
> > From: peter pilsl [mailto:pilsl at goldfisch.at]
> > Sent: Saturday, April 02, 2005 3:32 PM
> > To: Schröttner Robert
> > Cc: vienna-pm at mail.pm.org
> > Subject: Re: [Vienna-pm] Fragen zu Threads
> > 
> >  Für mich sind threads und prozesse  tatsächlich ein Mus/Einerlei und ich würde 
> > mich freuen, wenn  hier jemand kurz den Unterschied zusammenfasst. Vor allem
> > in Hinblick  auch auf mod_perl.
> > 
> 
> Ein Schnellschuss, was mir gerade so einfällt ;-)
> 
> Ein Prozess ist ein dynamisches Objekt in Betriebssystemen, mit Eigenschaften wie
>    - Prozess-Identifikation
>    - Prozesszustand (Befehlszähler; running/ready/waiting/...)
>    - Owner (User)
>    - Adressraum mit Code-, Daten-, Stack-Segment(en) in einem eigenen Adressraum, der
>      gegenüber alle andere Prozesse geschützt ist
>    - Environment
>    - Working directory
>    - Priorität
> 
> Kommunikation und Synchronsiation zwischen (POSIX)-Prozessen ist mit Pipes
> und Message Queues bzw. Semaphore möglich. Segmente können ebenfalls durch

Oder über Files.

> Sharing gemeinsam benützt werden, sodass Kommunikation auch über irgenwelche
> Datenstrukturen im Speicher möglich ist. Signals könnten auch zur Kommunikation
> verwendet werden, was aber i.a. nicht empfehlenswert ist.

Warum?
Signals mögen sehr primitiv sein, aber z.T. *muß* man sie verwenden und
es relativ einfach.

> Ein Prozess ist - auch in relativ effizienten Implementierungen - ein relativ teures
> Konzept, um viele kooperierende sequentielle Programme zu einer Aufgabenlösung
> heranzuziehen.

Ja, wenn man Slowlaris verwendet hatte. Inzwischen scheduled der
Solaris-Kernel ebenso wie er Linux-Kernel tatsächlich Threads. Innerhalb
des Linux-Kernels gibt es beim Scheduling tatsächlich keinen Unterschied
zwischen Threads und Prozessen - da gibt es Tasks und manche verwenden
(großteils) den gleichen Speicher und manche eben nicht (und das ist dem
Scheduler ziemlich egal).

Für mich ist ein Prozess ein Haufen Speicher, auf dem ein oder mehrere
Threads arbeiten.

> Threads sind der Ansatz, um diese Parallelität im Rahmen eines Prozesses zu bieten.
> Typisch wird das verwendet, um separate sequentielle Abläufe für verschiedene Input-Quellen
> (zB Socket), logische Abläufe (zB Request-Behandlung in einem Server) oder zeitabhängige
> Verarbeitungen schreiben zu können. (Select hat irgendwann auch seine Grenzen; für
> Message queues gibt's so etwas überhaupt nicht.)

MsgQ verwendet auch kaum einer wirklich.
poll()/select() wird für non-blocking I/O üblicherweise eingesetzt.
Abgesehen davon kann jeder Filedescriptor auf non-blocking geschalten
wedern und MagQ können auch non-blocking lesen.

> Threads bilden die Quasi-Parallelität im Rahmen eines Prozesses nach. Ein Thread hat
> innerhalb eines Prozesses ein Privatleben mit:
>   - Thread-Id
>   - Thread-Zustand (Befehlszähler; running/ready/waiting/...)
>   - Priorität
>   - Stack
>   - Signal-Behandlung

Die Signal-Behandlung ist konzeptionell das mühsamste an Threads - zumal
es Signals viel länger gibt wie Threads. 
Wenn man threads einfach so startet, ist es idR nicht definiert, welcher
Thread tatsächlich das Signal bekommt.

> Die Idee dabei ist, dass viele Threads effizienter zu verwalten sind als gleich viele Prozesse.

Naja, die ersten Thread-Implementierungen waren Libs im Userspace - da
hat man sich relativ teure fork()s (siehe Slowlaris) gespart (und dafür
das Problem eingekauft, das ein Haufen Standard-Lib-C-Funktionen u.U.
nicht mehr so ohne weiteres benutzt werden können - z.B. inet_ntoa(),
strtok(), etc.). Dann muß man die _r Versionen verwenden und/oder mit
Thread-Local-Storage arbeiten.

Bei den NPTL in Linux ist das ganze mit dem Kernel verheiratet und auf
Linux waren fork()s immer schon ziemlich billig. Dazu kommt COW.

Kurzum: Das ist sehr entbehrliches Zeug - außer vielleicht für eine
kleine Menge von Spezialapplikationen.

> Threads gibt es in diversen Variationen.
> 
> In C können POSIX-Threads verwendet werden. Das API kennt Aufrufe zum Starten
> von Threads (mit einer Function); zu Beenden; Synchronisationsmechanismen (Mutex,
> Semaphore, Condition Variable). Da alle Threads den Adressraum ihres Prozesses
> gemeinsam haben, ist der Zugriff auf (externe bzw. statische) Variable möglich, wobei
> für Synchronisation explizit gesorgt werden muss. POSIX-Threads können bzw. müssen
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Ob der Aufwand und Fehleranfälligkeit den (je nach OS größerne oder
kleineren) Performancegewinn rechtfertigt?

> durch das Betriebssystem über alle Prozesse eines Rechners hinweg einheitlich
> verwaltet werden.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services