Zauważyłem, że blokada zapisu ReentrantReadWriteLock zapewnia metodę isHeldByCurrentThread(), aby sprawdzić, czy wątek wywołujący trzyma tę blokadę.Dlaczego nie ma sposobu sprawdzenia, czy bieżący wątek zawiera blokadę odczytu ReentrantReadWriteLock?
Ale nie ma odpowiadającej metodzie isHeldByCurrentThread() dla blokady odczytu. Dlaczego nie?
Myślę, że odpowiedź znajduje się w komentarzu Douga Leasa, który podał dla tego numeru: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6207928.
Doug Lea pisze:
Obecna konstrukcja i zachowanie są zamierzone. Zamki do odczytu zazwyczaj nie są zdefiniowane jako mające własność, więc nie można sprawdzić własności. ... JSR166 EG otrzymał kilka żądań, aby opcjonalnie obsługiwać śledzenie odczytu i wstrzymania dla wątków. Takie działanie znacznie zwiększyłoby obciążenie zamka, więc musiałoby być zarządzane przez opcjonalny parametr konstrukcyjny. Patrzymy w to.
ReentrantReadWriteLock.getReadHoldCount() wydaje się wykonywać zadanie.
, o ile twój kod nie wykonuje ponownego odczytu, to zadziała – Renan
Nie, to nie działa. Załóżmy, że ThreadA uzyskał blokadę odczytu. Liczba jest teraz 1. Zanim wątek A zwalnia blokadę, ThreadB polega na getReadHoldCount()> 0 i wprowadza kod "chroniony". Teraz ThreadA a zwalnia blokadę, ale ThreadB nadal znajduje się w chronionym kodzie. ThreadC wchodzi w grę, nabywa blokadę zapisu, pobiera ją (ponieważ liczba czytelników wynosi zero) i aktualizuje niektóre dane. -> ThreadB widzi niespójne dane. – Heri
Ok, zrozumiałem. Niemniej jednak spodziewałem się, że istnieje sposób sprawdzenia, czy bieżący wątek zawiera blokadę odczytu ReentrantReadWriteLock. – rollaeriu360