[Vienna-pm] Fragen zu Threads

LAUN Wolfgang wolfgang.laun at alcatel.at
Sun Apr 3 23:32:07 PDT 2005


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

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

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

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 Idee dabei ist, dass viele Threads effizienter zu verwalten sind als gleich viele Prozesse.

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
durch das Betriebssystem über alle Prozesse eines Rechners hinweg einheitlich
verwaltet werden.

Einfacher verwendbar sind Thread-Modelle, die in eine Programmiersprache eingebaut sind.
Der Vorteil dabei ist der, dass Daten, die von verschiedenen Thread benützt werden, mit einem
Attribut versehen werden können, das den Compiler dazu bewegt, die erforderlichen Synchronisationsoperationen automatisch einzubauen. (Das Konzept ist ziemlich alt; über
"Regions" und "Monitore" wurde schon vor >30 Jahren geschrieben.) Andererseits sind dort
Threads i.a. in jedem Prozess getrennt zu verwalten; zwischen Prozessen (auch wenn sie
in der gleichen Sprache geschrieben sind) müssen dann wieder die Mechanismen der
Prozess-Ebene eingesetzt werden.

Threads gibt es in Ada ("Task") und in CHILL (heißt dort verwirrenderweise "Prozess" bzw. "Instanz").
Java und C++ verbinden Threads mit Objekten, die eine "run"-Methode haben müssen. Tja, und dann gibt es Threads auch in Perl...

HTH
Wolfgang






> 
> lg
> peter
> 


More information about the Vienna-pm mailing list