Czy istnieje nieczytelny ReadWriteLock, którego mogę użyć?

Question

Potrzebuję ReadWriteLock, który NIE jest reentrant, ponieważ blokada może zostać zwolniona przez inny wątek niż ten, który go uzyskał. (Zdałem sobie z tego sprawę, gdy zacząłem sporadycznie przechwytywać IllegalMonitorStateException.)

Nie jestem pewien, czy termin ten jest prawidłowy. ReentrantLock pozwala, aby wątek, który obecnie trzyma, blokuje, aby go ponownie zdobyć. NIE chcę tego zachowania, dlatego nazywam to "nierealnym".

Kontekst polega na tym, że mam serwer gniazd przy użyciu puli wątków. NIE ma wątku na połączenie. Żądania mogą być obsługiwane przez różne wątki. Połączenie klienta może wymagać zablokowania w jednym żądaniu i odblokowania w innym żądaniu. Ponieważ żądania mogą być obsługiwane przez różne wątki, muszę mieć możliwość blokowania i odblokowywania w różnych wątkach.

Założę dla tego pytania, że ​​muszę pozostać przy tej konfiguracji i że naprawdę muszę zablokować i odblokować w różnych żądaniach, a zatem prawdopodobnie różnych wątków.

Jest to ReadWriteLock, ponieważ muszę zezwolić na wiele "czytników" LUB na wyłączne "pisarz".

Wygląda na to, że można to napisać przy użyciu programu AbstractQueuedSynchronizer, ale obawiam się, że jeśli sam go napiszę, popełnię subtelny błąd. Mogę znaleźć różne przykłady użycia AbstractQueuedSynchronizer, ale nie ReadWriteLock.

Mogę wziąć źródło OpenJDK ReentrantReadWriteLock i spróbować usunąć element ponownie występujący, ale znowu obawiam się, że nie zrozumiałbym tego poprawnie.

Sprawdziłem w Guava i Apache Commons, ale nie znalazłem nic odpowiedniego. Apache Commons ma RWLockManager, który może zrobić to, czego potrzebuję, ale nie jestem pewien i wydaje się bardziej skomplikowany niż potrzebuję.

Answer 1

Semafor umożliwia różne wątki do wykonywania i wydawania zezwoleń. Wyjątkowy zapis jest równoznaczny z posiadaniem wszystkich zezwoleń, ponieważ wątek czeka, aż wszystkie zostaną zwolnione, a inne wątki nie mogą uzyskać dodatkowych zezwoleń.

final int PERMITS = Integer.MAX_VALUE; 
Semaphore semaphore = new Semaphore(PERMITS); 

// read 
semaphore.acquire(1); 
try { ... } 
finally { 
    semaphore.release(1); 
} 

// write 
semaphore.acquire(PERMITS); 
try { ... } 
finally { 
    semaphore.release(PERMITS); 
} 

Answer 2

Nie jestem pewien, czy rozumiem pytanie. Nie-reentrantowy ReadWriteLock jest oksymoronem IMO, który podaje słowo "reentrant" has specific meaning w języku ojczystym. Musi być użyteczny z wielu wątków, inaczej nie zadziała. Jest tylko ReentrantReadWriteLock, który implementuje ReadWriteLock w JDK Java 6, które widzę. Z pewnością wiele odczytów może jednocześnie zablokować ReadWriteLock, ale użycie słowa "powtórka" w tym kontekście jest mylące.

Co należy zrobić, to mieć dobre wzorce blokowania i odblokowywania kodu. Na przykład zawsze używaj bloków try {} finally, aby mieć pewność, że otrzymasz odblokowanie.

ReadWriteLock readWriteLock = new ReentrantReadWriteLock(); 
Lock readLock = readWriteLock.readLock(); 
... 
readLock.lock(); 
try { 
    ... // do stuff with the data 
} finally { 
    readLock.unlock(); 
} 

Sugestia, że ​​jeden wątek będzie lock() i inny unlock() nie jest tak jak powinno być za pomocą ReadWriteLock. To zły wzór.

wygląda to może być napisane przy użyciu AbstractQueuedSynchronizer

Ale to by cierpieć z tymi samymi problemami, które występują obecnie. Jeśli nie korzystasz z niego w odpowiedni sposób, nadal będziesz mieć dostęp do wątków mających dostęp do chronionego Collection poza blokadą.

zacząłem się IllegalMonitorStateException przerwami

jestem nie byłoby szybkie winę swoją ReadWriteLock do tego. Podejrzewam raczej, że masz jakiś kod, który jest , a nie blokowania kolekcji lub, że przez przypadek modyfikujesz kolekcję w blokadzie odczytu.

Answer 3

Nie do końca pewny, czego potrzebujesz, szczególnie. dlaczego powinien to być blokada zapisu do odczytu, ale jeśli masz zadanie, które musi być obsługiwane przez wiele wątków i nie chcesz, aby był on przetwarzany/dostępny jednocześnie, użyłbym w rzeczywistości ConcurrentMap (itd.).

Możesz usunąć zadanie z mapy lub zastąpić je specjalnym "obiektem blokady", aby wskazać, że jest zablokowane. Możesz przywrócić zadanie ze zaktualizowanym stanem do mapy, aby umożliwić przejęcie innego wątku, lub możesz przekazać zadanie bezpośrednio do następnego wątku i pozwolić mu na zamianę zadania na mapę.

Answer 4

Wiem, że już zaakceptowałeś inną odpowiedź. Ale wciąż myślę, że masz zamiar stworzyć dla siebie koszmar. W końcu klient nie wróci i zwolni te pozwolenia, a ty zaczniesz się zastanawiać, dlaczego "pisarz" nigdy nie pisze.

Gdybym to robić, zrobiłbym to tak:

Client issues a request to start a transaction 
The initial request creates a task (Runnable/Callable) and places it in an Executor for execution 
The initial request also registers that task in a Map by transaction id 

Client issues the second request to close the transaction 
The close request finds the task by transaction id in a map 
The close request calls a method on the task to indicate that it should close (probably a signal on a Condition or if data needs to be passed, placing an object in a BlockingQueue) 

Teraz zadanie transakcja musiałaby kodu:

public void run() { 
    readWriteLock.readLock().lock(); 
    try { 
     //do stuff for initializing this transaction 
     if (condition.await(someDurationAsLong, someTimeUnit)({ 
      //do the rest of the transaction stuff 
     } else { 
      //do some other stuff to back out the transaction 
     } 
    } finally { 
     readWriteLock.readLock.unlock(); 
    } 
} 

Answer 5

zdają się mieć upuścił piłkę ten, wycofując com.sun.corba.se.impl.orbutil.concurrent.Mutex;

Mam na myśli to, kto przy zdrowych zmysłach myśli, że nie będziemy potrzebowali zamków nierezydencyjnych. Jesteśmy tutaj, marnując czasy, spierając się o definicję reentrant (może nieznaczna zmiana w znaczeniu w ramce btw). Tak, chcę spróbować Zaciągnąć na tym samym wątku, czy to takie złe? to nie będzie impas, ponieważ inni z niego nie będą. Nierezydencyjna blokada, która blokuje się w tym samym wątku, może być bardzo przydatna, aby zapobiec błędom w aplikacjach GUI, w których użytkownik naciska szybko i wielokrotnie na ten sam przycisk. Byłem tam, zrobiłem to, QT miało rację ... znowu.