Брюс Эккель - Философия Java3
print(this + " " + "берет правую").
right takeO.
print(this + " " + "берет левую"); left. takeO.
print(this + " " + "ест"); pauseO; right dropO; left.dropO.
}
} catchdnterruptedException e) {
print(this + " " + "выход через прерывание"),
public String toStringO { return "Философ " + id; } } /// ~
В методе Philosopher.run() все философы непрерывно переходят от размышлений к еде, и наоборот. Метод pause() делает паузу случайной продолжительности, если значение ponderFactor отлично от нуля. Итак, Philosopher думает в течение случайного промежутка времени, затем пытается захватить левую и правую палочки вызовами take(), ест в течение случайного промежутка времени, а затем все повторяется.
В следующей версии программы возникает взаимная блокировка:
// concurrency/DeadlockingDiningPhi1osophers.java // Демонстрация скрытой возможности взаимной блокировки II {Args 0 5 timeout} import java util concurrent *.
public class DeadlockingDiningPhi1osophers {
public static void main(String[] args) throws Exception { int ponder = 5, if(args length > 0)
ponder = Integer.parselnt(args[0]); int size = 5; if(args length > 1)
size = Integer parselnt(args[l]); ExecutorService exec = Executors newCachedThreadPoolО; Chopstick[] sticks = new Chopstick[size]; for(int i = 0; i < size; i++)
sticksCi] = new ChopstickO; for(int 1=0. i < size, i++)
exec execute(new PhiTosopherC
sticks[i], sticks[(i+l) % size], i, ponder)); if(args length == 3 && args[2].equals("timeout")) TimeUnit.SECONDS sleep(5);
else {
System.out.рппШСНажмите 'Enter', чтобы завершить работу"); System in readO;
}
exec shutdownNow();
}
} ///:-
Если философы почти не тратят время на размышления, они будут постоянно конкурировать за палочки при попытках поесть, и взаимные блокировки возникают гораздо чаще.
Первый аргумент командной строки изменяет значение ponder, влияющее на продолжительность размышлений. Если философов очень много или они проводят большую часть времени в размышлениях, взаимная блокировка может и не возникнуть, хотя ее теоретическая вероятность отлична от нуля. С нулевым аргументом взаимная блокировка наступает намного быстрее.
Объектам Chopstick не нужны внутренние идентификаторы; они идентифицируются по своей позиции в массиве sticks. Каждому конструктору Philosopher передаются ссылки на правую и левую палочки Chopstick. Последнему Philosopher в качестве правой палочки передается нулевой объект Chopstick; круг замыкается. Теперь может возникнуть ситуация, когда все философы одновременно попытаются есть, и каждый из них будет ожидать, пока сосед положит свою палочку. В программе наступает взаимная блокировка.
Если философы тратят на размышления больше времени, чем на еду, вероятность взаимной блокировки значительно снижается. Даже может возникнуть иллюзия, что программа свободна от блокировок (при ненулевом значении ponder или большом количестве объектов Philosopher), хотя на самом деле это не так. Именно этим и интересен настоящий пример: программа вроде бы ведет себя верно, тогда как на самом деле возможна взаимная блокировка.
Для решения проблемы необходимо осознавать, что тупик имеет место при стечении следующих четырех обстоятельств:
1. Взаимное исключение: по крайней мере один ресурс, используемый потоками, не должен быть совместно используемым. В нашем случае одной палочкой для еды не могут одновременно есть два философа.
2. По крайней мере одна задача должна удерживать ресурс и ожидать выделения ресурса, в настоящее время удерживаемого другой задачей. То есть для возникновения тупика философ должен сохранять при себе одну палочку и ожидать другую.
3. Ресурс нельзя принудительно отбирать у задачи. Все процессы должны освобождать ресурсы естественным путем. Наши философы вежливы и не станут выхватывать палочки друг у друга.
4. Должно произойти круговое ожидание, когда процесс ожидает ресурс, занятый другим процессом, который в свою очередь ждет ресурс, удерживаемый еще одним процессом, и т. д., пока один из процессов не будет ожидать ресурса, занятого первым процессом, что и приведет к порочному кругу. В нашем примере круговое ожидание происходит потому, что каждый философ пытается сначала получить правую палочку, а потом левую.
Так как взаимная блокировка возникает лишь при соблюдении всех перечисленных условий, для упреждения тупика достаточно нарушить всего лишь одно из них. В нашей программе проще всего нарушить четвертое условие: оно выполняется, поскольку каждый философ старается брать палочки в определенном порядке — сначала левую, потом правую. Из-за этого может возникнуть ситуация, когда каждый из них держит свою левую палочку и ждет освобождения правой, что и приводит к циклическому ожиданию. Если инициализировать последнего философа так, чтобы он сначала пытался взять левую палочку, а потом правую, взаимная блокировка станет невозможна. Это всего лишь одно решение проблемы, но вы можете предотвратить ее, нарушив одно из оставшихся условий (за подробностями обращайтесь к специализированной литературе по многозадачному программированию):
//. concurrency/FixedDiningPhilosophers.java
// Обедающие философы без взаимной блокировки.
// {Args: 5 5 timeout}
import java.util.concurrent.*;
public class FixedDiningPhilosophers {
public static void main(String[] args) throws Exception {
int ponder = 5; if (args.length > 0)
ponder = Integer.parselnt(args[0]), int size = 5, if(args.length > 1)
size = Integer parselnt(args[l]); ExecutorService exec = Executors.newCachedThreadPool(); Chopstick[] sticks = new Chopstick[size]. for(int i = 0, i < size; i++)
sticks[i] = new ChopstickO; for(int i = 0: i < size; i++) if(i < (size-1))
exec execute(new Philosopher(
sticks[i], sticks[i+l], i, ponder));
else
exec.execute(new Philosopher(
sticksEO], sticksEi], i, ponder)), if(args.length == 3 && argsE2].equals("timeout")) TimeUnit SECONDS.sleep(5);
else {
System out printlnC'Press 'Enter' to quit"); System, in. readO.
}
exec shutdownNow().
}
} ///:-
Проследив за тем, чтобы последний философ брал и откладывал левую палочку раньше правой, мы устраняем взаимную блокировку.
В языке Java нет встроенных средств предупреждения взаимных блокировок; все зависит только от вас и аккуратности вашего кода. Вряд ли эти слова утешат того, кому придется отлаживать программу с взаимной блокировкой.
Новые библиотечные компоненты
В библиотеке java.utiLconcurrent из Java SE5 появился целый ряд новых классов, предназначенных для решения проблем многозадачности. Научившись пользоваться ими, вы сможете создавать более простые и надежные многозадачные программы.
В этом разделе приведено немало примеров использования различных компонентов. Другие, относительно редко встречающиеся компоненты, здесь не рассматриваются.
Так как компоненты предназначены для решения разных проблем, простого способа их упорядочения не существует, поэтому мы начнем с более простых примеров и постепенно перейдем к более сложным.
CountDownLatch
Класс синхронизирует задачи, заставляя их ожидать завершения группы операций, выполняемых другими задачами.
Объекту CountDownLatch присваивается начальное значение счетчика, а все задачи, вызвавшие await() для этого объекта, блокируются до момента обнуления счетчика. Другие задачи могут уменьшать счетчик, вызывая метод countDown() для объекта (обычно это делается тогда, когда задача завершает свою работу). Класс CountDownLatch рассчитан на «одноразовое» применение; счетчик не может возвращаться к прежнему состоянию. Если вам нужна версия с возможностью сброса счетчика, воспользуйтесь классом CyclicBarrier.
Задачи, вызывающие countDown(), не блокируются на время вызова. Только вызов await() блокируется до момента обнуления счетчика.
Типичный способ применения — разделение задачи на п независимых подзадач и создание объекта CountDownLatch с начальным значением п. При завершении каждая подзадача вызывает countDown() для объекта синхронизации. Потоки, ожидающие решения общей задачи, блокируются вызовом await(). Описанная методика продемонстрирована в следующем примере:
// concurrency/CountDownLatchDemo java import java.util concurrent.*; import java util *.
import static net mindview util.Print *,
// ЧАсть основной задачи.
class TaskPortion implements Runnable {
private static int counter = 0.
private final int id = counter++;
private static Random rand = new Random(47);
private final CountDownLatch latch;
TaskPortion(CountDownLatch latch) { this latch = latch,
}
public void run() { try {
doWorkO;
latch countDownO; } catchdnterruptedException ex) {
// Приемлемый вариант выхода
}
}
public void doWorkO throws InterruptedException {
TimeUnit MILLISECONDS.sleep(rand nextlnt(2000)); pri nt(thi s + "завершается");
}
public String toStringO {
return String.format("^l$-3d ". id),
// Ожидание по объекту CountDownLatch: class WaitingTask implements Runnable { private static int counter = 0; private final int id = counter++; private final CountDownLatch latch, WaitingTask(CountDownLatch latch) { this latch = latch;
public void run() { try {
latch awaitO.
printC'Bapbep пройден для " + this); } catchdnterruptedException ex) {
print(this + " interrupted"),
}
}
public String toStringO {
return String format("WaitingTask %l%-36 id).
public class CountDownLatchDemo { static final int SIZE = 100.
public static void main(String[] args) throws Exception {
ExecutorService exec = Executors.newCachedThreadPoolО, // Все подзадачи совместно используют один объект CountDownLatch CountDownLatch latch = new CountDownLatch(SIZE); for(int i = 0; i < 10; i++)
exec.execute(new WaitingTask(1atch)); for(int i = 0; i < SIZE. i++)
exec execute(new TaskPortion(latch)). print("Запущены все задачи"); exec.shutdownO, // Выход по завершению всех задач
}
} /// ~
TaskPortion некоторое время ожидает, имитируя выполнение части задачи, а класс WaitingTask представляет некую часть системы, которая обязана дождаться завершения всех подзадач. Все задачи используют один и тот же объект CountDownLatch, определяемый в main().
