parę pytań ze współbieżności

Załóżmy, że nie korzystamy z synchronizacji, lecz z monitorów ( z zmiennych Condition i Lock).
Załóżmy też, że mamy współdzielony zasób do którego chcemy kontrolować dostęp.
Mamy trzy typy wątków:
Typ1 to taki wątek, że wiele wątków tego typu może korzystać z zasobu, ale nie może w tym czasie korzystać wątek typu drugiego oraz trzeciego.
Typ2 to taki wątek, że w danym czasie może korzystać on i tylko on.
Typ3 tak samo jak drugi z jedną różnicą. Może on wywłaszczyć zasób jeżeli zechce skorzystać.
Pytania:

1. Jak zorganizować to, żeby wątki typu pierwszego mogły korzystać naraz zasobu?
2. Jak wywłaszczać zasób w wątku trzecim?
3. Na początku każdej metody "sterującej" wątkiem rozważam blokowanie Locka ( locker.lock() ). Tak się zastanawiam, co się stanie, jeżeli na początku zrobimy locker.lock(), a locker będzie już zablokowany?

P.S Wątki są już w systemie. Mamy jedynie napisać metody sterujące. Np. Jeżeli mamy wątek typu pierwszego to on wygląda mniej więcej tak:
jakaś pętla:
uzyskaj_dostęp();
coś tam zrób();
oddaj_zasób();

I napiszmy uzyskaj_dostep() oraz oddaj_zasób();

W Javie standardowa synchronizacja, poza bardzo nielicznymi przypadkami (np. adaptive spin lock) realizowana jest za pomoca monitorow be wzgledu na to czy uzywany jest intrinsic lock (sekcja synchronized), czy AbstractQueuedSynchronizer (ReentrantLock).
Jesli zalezy Ci na zachowaniu spojnosci (a zakladam ze tak), to nie da sie zrobic tego, co opisales. Wynika to wprost z JSR-133, czyli modelu pamieci w Javie.
Sekcje krytyczna stosuje sie zeby uzskac gwarancje:

1. widocznosci (zmian)
2. sekwencyjnosci (zmian)
3. atomowosci (zmian)

Jesli dobrze rozumiem, to chcesz zeby watki typu 1. mogly wspolbieznie uzyskiwac dostep do sekcji krytycznej. Taki scenariusz jest zaprzeczeniem samej istoty sekcji krytycznej.
Typ 2. to klasyczny mutex wiec mozesz go zrealizowac za pomoca synchronized czy ReentrantLock z takim samym efektem.
Jesli chodzi o typ 3. to nie da sie zrealizowac czegos takiego jak preemptive synchronization. Wykonaj eksperyment myslowy i sprobuj zastanowic sie nad tym jak wywlaszczajac watek w polowie sekcji krytycznej i zmuszajac go do zwolnienia monitora - maszyna wirtualna, system operacyjny i CPU moga zagwarantowac jakakolwiek spojnosc.

Wspoldzielony dostep mozliwy jest tylko dla scenariuszy w ktorych jeden watek modyfikuje wartosci w sekcji krytycznej, podczas gdy pozostale moga owe wartosci jedynie odczytac. Modyfikacja zawsze implikuje mutex.
Polecam zapoznac sie z Read- i WriteLock oraz JMM cookbook

Dziękuję za odpowiedź :)
Najprawdopodobniej mnie Pan źle zrozumiał, albo ja się źle określiłem, co bardziej prawdopodobne ;).
W istocie chodzi o implementację problemu czytelników i pisarzy.
I właśnie chodzi o to, że czytelnicy mogą przecież czytać w kilkoro. Jest to klasyczny problem z jedną modyfikacją, a mianowicie obok pisarzy i czytelników jest jeden wątek- "właściciel" tego zasobu. Chcemy teraz potrafić napisać takie metody, które będą dopuszczały do zasobu, bądź zatrzymywały na kolejce zmiennej condition.
Właśnie ten rzeczony właściciel ma mieć możliwość wywłaszczenia zasobu i go zajęcia.
Myślę, że słowo sekcja krytyczna jest tu niewłaściwe.
Dziękję i pozdrawiam! :)

Z punktu widzenia sekwencji store - store określenie "sekcja krytyczna" jest jak najbardziej uzasadnione.
Nie za bardzo rozumiem po co ci condition.
Tak jak napisałem w poprzedniej odpowiedzi: poczytaj o read/write locks.

nawet i użyłbym tej Read/write lock, ale w zadaniu mam zastrzeżone, że nie mogę używać bloków synchronizowanych, semaforów oraz właśnie ReadWrite Lock