В Java Параллелизм на практике Б. Гетц, раздел 13.5 сказал:ярмарка замок в ReeantrantReadWriteLock
В Java 5.0, блокировка чтения ведет себя больше как семафора, чем замок, поддерживая только число активных читателей, а не их личности. Поведение было изменено на Java 6, чтобы отслеживать также, какие потоки получили замок чтения6.
6 Одна из причин этого изменения является то, что под Java 5.0, реализация блокировки не может различить нить запрашивающего читать замок в первый раз и возвратный запрос блокировки, который сделал бы справедливойблокировка чтения-записи тупиковая блокировка.
Мой вопрос в том, что не так с честностью? Почему был несправедливый замок для чтения и записи, защищенный от тупика?
Не могли бы вы объяснить, что он имел в виду? Я имею в виду, в каких обстоятельствах fair блокировка чтения и записи под Java 5 вызывает тупик? И если он вел себя как Semaphore, почему не явилась ошибка Semaphore?
Возможно, вам захочется остановиться и спросить, что же справедливо? В настольной или серверной среде процессы часто конкурируют друг с другом за процессорное время. «Справедливость» в планировщике гарантирует, что каждый конкурирующий процесс получает справедливую долю. Но в рамках одной программы потоки должны _cooperate_ вместо конкуренции. И, когда нужно выполнить работу, не важно, какой поток выполняет эту работу. Если в пуле есть два рабочих потока, и для них всего одна половина работы для них, это ничего не повредит, если рабочая нагрузка не будет распределена «справедливо». –
@jameslarge в контексте получения прав на блокировку указывает, что потоки, конкурирующие за одну и ту же блокировку, приобретают ее в том порядке, в котором они ее запрашивали. – bowmore
@bowmore, я понимаю, что «справедливость» в планировщике - это не совсем то же самое, что «справедливая» реализация мьютекса, но это не совпадение, что они имеют одно и то же имя. Оба они предназначены для обеспечения того, чтобы потоки/процессы получали «справедливый» доступ, когда они конкурируют за ресурсы. Я сомневаюсь в важности «честных» мьютексов, потому что, когда я пишу многопоточный код, я не хочу, чтобы мои потоки честно конкурировали: я хочу, чтобы они не конкурировали вообще. Это трудная цель, но ИМО стоит того, чтобы добиться успеха. –