JNI / wątki

Rozpoznawał ktoś temat mapowania wątków Java na wątki natywne?

Mam następującą sytuację:

• biblioteka natywna A, która wykorzystuje POSIX Threads (w szczególności korzystam w niej z mechanizmu Thread Local Storage - *pthread_getspecific *)
• biblioteka natywna B, która korzysta z A
• biblioteka natywna C, która również korzysta z A
• biblioteki B i C są od siebie niezależne

Od strony Javy, korzystam z biblioteki B i C poprzez interfejs JNI. Aplikacja Javowa jest wielowątkowa i wywołuje funkcjonalności z biblioteki B i C (dla B i C, operacje wykonywane via JNI są synchronizowane).

Wydaje mi się, że są następujące możliwości:
a) 1:1 - dla wątku JVM odpalany jest wątek natywny i przez cały czas życia wątku javowego, jest on związany z konkretnym wątkiem natywnym
b) 1:M - wątek javowy może być wykonywany przez wiele wątków natywnych (np. java wątek idzie spać, po ponownym obudzeniu może być kontynuowany przez dowolny wątek OS)

..ale możliwe, że coś przeoczyłem.

I ponownie, wydaje mi się, że to mapowanie jest zależne od implementacji JVM, a specyfikacja niekoniecznie musi się do mapowania odnosić.

Teraz pytanie właściwe, jak wątki Javowe mapują się na wątki systemowe? :)

Wydaje mi się że mieszasz tutaj dwie kwestie.

Strona 1. Tworząc wątek z javy z samej javy poprzez new Thread... sposób jest faktycznie zależny od implementacji maszyny wirtualnej java.
Strona 2 (tutaj mogę się mylić). Jeżeli odpalasz kod natywny przez JNI i w nim tworzony jest kolejny wątek. Na początku sprostuję, bo nie jestem pewny czy dobrze zrozumiałem, ale podczas wywoływania metod przez JNI nie jest tworzony nowy wątek, tylko dzieje się to w tym który JVM już posiada i z którego zostało zrobione wywołanie. Załóżmy jednak że wątek jest tworzony już w kodzie natywnym. Dla tego przypadku JVM nie jest szeryfem i nie ma nic do powiedzenia, bo potrzeba stworzenia nowego wątku nie została przez nią zgłoszona tylko przez kod natywny.

Proszę aby ktoś ogarnięty skomentował/sprostował moją wypowiedź :).

@krzysiek050:

W sumie pytanie można zreudkować do: "Jak natywne Thread Local variable ma się do wątku Javowego"

W moim przypadku, kod natywny nie tworzy nowych wątków natywnych, ale przechowuje dane per wątek natywny (Thread Local variable, w sensie natywny, a nie javowym). To znaczy, że jeśli klient biblioteki natywnej utworzy N wątków, to kod biblioteki będzie operował na danych charakterystycznych dla wątku.

Jeśli klientem biblioteki jest aplikacja natywna, to nie ma problemu. Wszystko ładnie śmiga. Model wątków javowych trochę komplikuje sprawy.

Załóżmy, że w JVM tworzone są 2 nowe wątki:

• Thread1
• Thread2

...zaś w implementacji JVM wykonywane są (dla uproszczenia) przez 1 wątek natywny, czyli:

• Thread1 zaczyna pracę (stan Running), coś tam liczy i nagle zaczyna czekać (stan Waiting)
• Thread2 w czasie gdzy Thread1 jest w stanie Waiting, może być wykonywany przez wątek natywny - no bo po co marnować CPU na czekanie np. 1s w Thread1,
  skoro można w tym czasie wykonać fragment Thread... i niestety Thread2 coś ustawia w Thread Local variable natywnym, nadpisując to co jest ustawione przez Thread1.

Moje odczucia jak na razie są takie, że powyższa sytuacja może wystąpić (nie mam pewności, stąd pytania w pierwszym poście).

Juz wiele lat temu zrezygnowano z green threads w JVM. Taka sytuacja jaka opisujesz nie zaistnieje. Kazdy watek w javie jest watkiem natywnym.
http://stackoverflow.com/questions/1888160/distinguish-java-threads-and-os-threads

Od czasów bodajże Javy 1.5 zarządzanie wątkami przerzucono z JVM do systemu. JVM udostepnia tylko wrappery na odpowiednie wywołania systemowe (i dobrze, bo dzięki temu jest to wydajniejsze i można łatwiej optymalizować JVM pod system).

Dzięki za wypowiedzi. Obawiałem się trochę tych green threadów, ale widać, że niepotrzebnie. Doczytałem i wygląda, że zrezygnowano z nich w okolicach Java 1.3.