Как видите, здесь, ReentrantLock использует _ 2_ как фактическая реализация очереди потоков. Видя, что ни один из его методов не может быть переопределен, вы не можете сделать это легко, то есть заменить стандартную очередь потоков на приоритетную очередь.
Но, как говорится в документации: «Этот класс обеспечивает эффективную и масштабируемую основу для синхронизации, частично за счет специализации диапазона его использования для синхронизаторов, которые могут полагаться на состояние int, параметры получения и выпуска, а также внутреннюю очередь ожидания FIFO. Когда этого недостаточно, вы можете создавать синхронизаторы на более низком уровне, используя атомарные классы, ваши собственные классы java.util.Queue и поддержку блокировки LockSupport ».
Вот что вам нужно сделать: построить свой собственный замок. Ваша основная цель - позволить методу release использовать очередь приоритетов для принятия решения. Если производительность не является проблемой, вы можете просто использовать стандартный PriorityQueue, где вы можете просто сделать его чтение и запись потокобезопасным с помощью synchronized, ReentrantLock или любой другой доступной стандартной блокировки. Трудно найти потокобезопасные очереди с приоритетом. Однако, если производительность важна, этот документ из 2003 года может быть вам интересен.
Однако, поскольку пользователь может изменить приоритет потока в любой момент времени, проще всего использовать базовую очередь и использовать стабильная сортировка (чтобы не нарушить порядок потоков с равным приоритетом) до перехода к следующему парню. Конечно, производительность будет плохой, если вы захотите использовать ее для критических разделов с высокой конкуренцией.
person
Domi
schedule
03.12.2013
