Как запросы на блокировку очереди StampedLock? - PullRequest
0 голосов
/ 03 мая 2018

Я занимаюсь блокировкой кэша на основе StampedLock ( javadoc здесь ) в Java8, но не могу найти убедительную реализацию в сети, несмотря на чтение таких статей, как идиомы StampedLock .

Я не испытываю особого оптимизма в отношении предложений многопоточности и параллелизма Java после шока, что ReentrantReadWriteLock не позволяет обновить блокировку чтения до блокировки записи, что сопровождается трудностями, связанными с надежным альтернативным решением ,

Моя проблема в том, что нет определенного утверждения, которое бы ослабило мои опасения, что StampedLock будет блокировать запросы на запись на неопределенный срок, пока запросы на чтение поставлены в очередь.

Глядя на документацию, есть 2 комментария, которые вызывают у меня подозрения.

Из Javadoc :

Политика планирования StampedLock не всегда предпочтительна читатели над писателями или наоборот. Все методы "попробовать" являются наилучшими и не обязательно соответствуют какой-либо политике планирования или справедливости.

Из исходного кода :

 * These rules apply to threads actually queued. All tryLock forms
 * opportunistically try to acquire locks regardless of preference
 * rules, and so may "barge" their way in.  Randomized spinning is
 * used in the acquire methods to reduce (increasingly expensive)
 * context switching while also ....

Таким образом, он намекает на очередь для блокировки чтения и записи, но мне нужно прочитать и переварить целые 1500 строк исходного кода, чтобы закрепить его.

Я предполагаю, что это должно быть там, потому что я нашел хорошую статью по тестированию , в которой показано, что StampedLock - это путь для многих операций чтения / записи. Однако я все еще обеспокоен из-за отсутствия освещения в Интернете.

В принципе, я предполагаю, что ожидал реализацию, где я мог бы подключить и воспроизвести после javadoc, но в конце концов я остался копаться в сети, задаваясь вопросом, почему нет нигде примера зацикленного StampedLock#tryOptimisticRead() - даже код из эталонной статьи этого не делает.

Так ли сложен параллелизм Java или я пропустил что-то очевидное?

1 Ответ

0 голосов
/ 03 мая 2018

"Является ли параллелизм Java таким сложным или я пропустил что-то очевидное?"

Это вопрос мнения 1 является ли параллелизм Java более сложным, чем (скажем) параллелизм C ++ или Python.

Но да, параллелизм затруднен 2 на любом языке, который позволяет различным потокам напрямую обновлять общие структуры данных. Языки, которые (только) поддерживают CSP-подобный параллелизм, легче понять и рассуждать.

Справка:


Если говорить конкретно, верно, что большинство форм блокировки в Java не гарантируют справедливость . И действительно, многие вещи, связанные с планированием потоков, (намеренно) слабо определены . Но нетрудно написать код, который позволит избежать этих проблем ... как только вы поймете библиотеки и как их использовать.


1 - Мое мнение таково, что поддержка параллелизма в Java, по крайней мере, легче рассуждать, чем большинство других языков его аналога. Модель памяти Java (глава 17.4 JLS) хорошо определена, и «Практический параллелизм Java» Гетца и др. Хорошо объясняет все входы и выходы параллельного программирования.

2 - .... для большинства программистов.

...