🚀 go-pugleaf

Dnia 29-11-2007, Cz o godzinie 14:12 +0100, Sebastian Kaliszewski pisze:

> W Py masz coś co się nazywa GIL czyli Globa Interpreter Lock. Przez wielu 
> znienawidzone, ale się trzyma i po bliższym przyjrzeniu się nie jest wcale 
> takie głupie.

Czy głupie, to zależy.

Ogólnie są różne metody realizowania wątków w języku programowania
implementowanym w typowym systemie operacyjnym (Unix albo Windows).

Oto trzy najważniejsze z nich:

1. Jeden wątek języka jest realizowany przez jeden wątek systemu
   operacyjnego. Program używa systemowego stosu tak jak w C.
   Program swobodnie woła blokujące funkcje systemowe tak jak w C.

   Przykłady: C, C++, Java (Sun obecnie, a także GNU), .NET (Microsoft,
   Mono), Lisp (SBCL na x86), Jython (używa bezpośrednio wątków Javy).

2. Wszystkie wątki języka są realizowane przez jeden wątek systemu
   operacyjnego. Implementacja języka używa własnego stosu, żeby można
   się było przełączać między różnymi stosami. Zamiast blokujących
   funkcji systemowych używane są nieblokujące odpowiedniki, żeby nie
   blokowały się inne wątki.

   Przykłady: niektóre Lispy, Erlang (stary), Ruby, SML/NJ,
   Java (Sun bardzo dawno temu - chyba), Glasgow Haskell (stary).

3. Jeden wątek języka jest realizowany przez jeden wątek systemu
   operacyjnego, ale w danej chwili chodzi tylko jeden taki wątek naraz
   (z wyjątkiem wołania funkcji w C, które wykonują się długo bez
   potrzeby dostępu do rantajmu języka). Program używa systemowego
   stosu tak jak w C. Program musi specjalnie oznaczać blokujące
   funkcje systemowe.

   Przykłady: OCaml, Python.

W pierwszej metodzie dużym problemem jest odśmiecanie. Poza tym wątków
nie może być zbyt dużo, a przełączanie między wątkami jest dość drogie.

W drugiej metodzie problemem jest niewykorzystanie potencjału
wielordzeniowych komputerów (chyba że przez rozbicie programu na osobne
procesy, co z powodzeniem stosuje Erlang). Kłopotliwe jest używanie
gotowych bibliotek, które zawierają funkcje wykonujące się długo bądź
które powodują przeplatanie się wywołań funkcji z różnych języków
(program może przykryć ramkę stosu funkcji w C ramką stosu funkcji
w C wykonywanej na rzecz innego wątku logicznego, a następnie spróbować
wrócić do tej pierwszej, kiedy druga jeszcze się nie skończyła).

Trzecia metoda łączy większość wad pierwszych dwóch. Wątków nie może być
zbyt dużo, a przełączanie między nimi jest jeszcze droższe niż w pierwszej
metodzie. Nie jest wykorzystywany potencjał wieloprocesorowych komputerów,
a funkcje wykonujące się długo muszą być specjalnie oznaczone. Nie lubię
tej metody. Główna zaleta: jest łatwa w realizacji.

Są i hybrydowe metody, mniej typowe:

4. Wątki języka są realizowane przez jeden wątek systemowy, chyba że
   wołane są blokujące funkcje w C bądź funkcje w C, które wołają
   z powrotem funkcje naszego języka - wtedy wątek systemowy staje się
   związany z jednym wątkiem logicznym, a do wykonywania innych wątków
   logicznych tworzone są pomocnicze wątki systemowe. W danej chwili
   tylko jeden wątek systemowy ma dostęp do rantajmu języka.

   Przykłady: Glasgow Haskell (między starym a nowym bądź nowy jako
   jedna z opcji), Kogut.

5. Jak wyżej, ale wiele wątków systemowych naraz ma dostęp do rantajmu
   języka (w praktyce jest sens, żeby było ich mniej więcej tyle ile
   rdzeni).

   Przykłady: Glasgow Haskell (nowy jako jedna z opcji),
   Erlang (nowy - nie jestem pewien).

Być może w niektórych przykładach się pomyliłem. Przykłady są niepełne.
Na pewno Ruby planuje jakąś zmianę realizacji wątków.

Wątki Erlanga mają semantykę bliższą tradycyjnym procesom (zresztą
nazywają się procesami): logicznie nie współdzielą danych, ale mogą
wymieniać się komunikatami. Fizycznie komunikaty mogą być częściowo
współdzielone; są immutable, więc współdzielenie jest nieobserwowalne.
Każdy wątek/proces ma własny odśmiecacz, przynajmniej w starym Erlangu.

Perl miał jedną nieudaną implementację wątków, zarzuconą, oraz nowszą,
w której współdzielone zmienne są odróżniane od niewspółdzielonych.

O ile wiem, PHP nie ma żadnych wątków.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/