Pull to refresh

Comments 9

Самый интересный объект в этом решении задачи обедающих философов — queue_node. Если для философа освободилась вторая палочка, то она извлекается из очереди, что влияет на готовность философа-соседа, и требует изменения его состояния. Это при прямолинейном программировании приводит к ровно тем же проблемам, как и исходная задача. Поэтому истинное решение задачи — не в графе, который вы здесь привели, а в реализации queue_node и ее взаимодействии с port'ами. Хотелось бы прочитать отдельный пост на эту тему.
Здесь дело скорее в реализации не queue_node, а join_node, и его взаимодействии с портами. Он пытается резервировать палочки на обоих входах. Если хоть одна не резервируется, все резервации снимаются. Только если сразу обе доступны, они извлекаются из очереди. На готовность соседа это конечно повлияет — если палочка зарезервирована, он её зарезервировать уже не сможет. queue_node просто предоставляет возможность извлечь объект из очереди, когда потребуется.
Вы выбрали крайне не удачный пример для демонстрации TTB. Причем и способ какой-то не такой подобран. Принцип исключения deadlock'а здесь «проверить и взять или положить» видится на TTB страшным монстром. А если бы зависимость была посложнее, чем от двух соседей? Я понимаю, что это — пример, но как-то — совсем не удачный.
Присоединяюсь. Тем более такое количество кода для данной задачи запросто отпугнет от TBB не только новичка. Навскидку, даже метод Гаусса был бы интереснее в качестве примера.
К этому примеру надо относиться не как к упрощённому «use-case»-y, а как к синтетическому примеру для демонстрации функционала join_node и динамической структуры графа без явного входа и выхода. И уж тем более не как к демонстрации всей TBB как таковой — о ней много чего можно написать, функционала и способов применения множество. Если вспомнили про Гаусса, может будет ближе этот пример (на английском).
«если философ может захватить одну палочку, но вторая занята – он отпустить первую и подождёт, не блокируя соседей понапрасну».

Это может привести к тому, что этот философ помрет от голода, что противоречит условию оригинальной задачи. У вас есть решение этого?
Если философ захватил палочки и есть, то после этого он обязательно думает, не пытаясь их захватывать. В это время есть будут соседи — умереть от голода они не должны.
Вы бы почитали обсуждение задачи, хоть на википедии. Проблема голодания — отдельный вопрос в задаче обедающих философов, и не каждое решение ее снимает. «Не должны» — это не доказательство.
Ok. Из предложенных в википедии вариантов решения, мой ближе всего к «решению на основе монитора». И наверное да, в предложенной реализации голодание будет возможно. Не должны, но могут.
Sign up to leave a comment.