Самый интересный объект в этом решении задачи обедающих философов — queue_node. Если для философа освободилась вторая палочка, то она извлекается из очереди, что влияет на готовность философа-соседа, и требует изменения его состояния. Это при прямолинейном программировании приводит к ровно тем же проблемам, как и исходная задача. Поэтому истинное решение задачи — не в графе, который вы здесь привели, а в реализации queue_node и ее взаимодействии с port'ами. Хотелось бы прочитать отдельный пост на эту тему.
Дедлоки тут не причем, они появляются от некорректного проектирования, а от техники реализации (synchronozed или read-write lock) — не зависят (ну, почти).
Открою вам небольшой секрет — то как вы передаете сообщения («с помощью synchronized при доступе к одним и тем же данным») — тоже можно трактовать как передачу сообщений. Если вы при этом еще используете notify(All) — то наверняка.
Может вы и правы, имея ввиду тестирование вебсайтов, которые все равно через полгода будут переделаны и ненайденные баги пропадут необнаруженными.
Но есть и другие продукты, с другими требованиями. например, Java компилятор и JVM. Казалось бы, прогнали компилятор через себя, работает, что еще надо? Но нет, при тестировании ставилась задача проверить все утверждения из спецификаций. Написано, что размер кода метода должен быть больше нуля и меньше 65536 — значит надо сделать методы длиной 0, 1, 65535 и 65536, и если 65536 машиной не отвергается — файлишь баг. Но это самай простая ситуация. А есть еще правила вывода типов переменных при слиянии ветвей исполнения, поведение volatile переменных (до появления нынешней memory model) и многие другие пыльные углы. И если бы тестировщики и разработчики относились к тестированию также как Вы, то Java никогда не стала бы столь популярной как сейчас.
Хуже всего в этом плане разработчикам тестов. Только и думаешь, как бы вывести на чистую воду программистов, а еще лучше авторов спецификаций (особенно если это люди всемирно известные). Профессиональная деформация как у следователей: «если вы еще не сидите, то это не ваша заслуга, а наша недоработка».
Так и не понял, причем здесь булева алгебра.
А вообще, как говорится, «идея ничего не стоит». Вы бы сделали бы сначала хоть маленький шаг, хотя бы обрисовали проблематику. По мне, так основная проблема в отсутствии единого формализованого языка. У меня вот тоже была глобальная идея (ну не настолько глобальная как у вас) и я все удивлялся почему ее никто не разрабатывает. Постоянно мониторил интернет, а потом оказалось, что идея разрабатывается, но просто используют другие термины для описания, и я этих работ не находил.
Вот как раз фигуры технического анализа — танцы с бубнами, на изучение которых не хочется тратить ни времени, ни денег. Хочется чего-то математически обоснованного.
Нобелевки математикам не дают. Но научившись восстанавливать формулы по графикам, нобелевки и не нужно — на бирже столько заработаешь, что сможешь основать премию имени себя.
Ну а где сама сложность? Как ее измерять? Как узнать, что график 5) на самом деле порождается простой формулой? И вообще, дан график, можно ли вычислить минимально сложную формулу, его порождающую?
«одно не очевидное правило. Если поток единовременно выполняет не больше одной синхронизации, то никаких дедлоков не будет»
Действительно, правило неочевидное. Очевидное правило выглядит так:
— дедлок — это цикл на графе ресусов, чтобы не попадать в дедлок, надо избегать циклов.
Для этого:
— все блокируемые ресурсы организуются в нециклический ориентированный граф. Иными словами, определяется частичный порядок на множестве ресурсов.
— блокировка нескольких ресурсов допускается только в последовательности, сохраняющей этот порядок.
«Но прошло уже более пятидесяти лет» — как можно такое писать, не прикинув в уме, сколько лет прошло на самом деле?
В оригинале, между прочим, «close to fifty years».
Ну это смотря какой продукт. Когда выпускали Андроид, спецификации были. Сейчас Гугл выпускает Дарт, спецификация была с самого начала, но неокончательная, в процессе разработки постоянно меняется. Тем не менее это спецификация, и ее существование позволяет вести тестирование.
Эфемерная истина, воспринимаемая на подсознательном уровне, может отражать лишь небольшие проекты — просто потому, что объем подсознания ограничен. А вот например реализация языка программирования или движка базы данных на подсознательном уровне невозможна, хотя некоторые и пытаются, по причине нелюбви к написанию документации.
Работая тестописателем в западной компании, я быстро усвоил простую вещь: тестирование — это проверка соответствия реализации и спецификации. При отсутствии формальной спецификации хоть затестируйся, качественного кода не получишь — просто потому что спецификация-то есть, без нее ни код, ни тесты не пишутся — но она в голове у программиста, и в головах разных программистов (разработчиков кода и тестов) — она разная.
И кстати, начинать разработку тестов надо с вычитки спецификации на предмет ошибок, противоречий и недоговоренностей.
Спецификация — краеугольный камень разработки и тестирования. Видимо, усвоение этой аксиомы и есть то, что нас ждет завтра.
Это выше уровнем, чем java.util.concurrent.
Но есть и другие продукты, с другими требованиями. например, Java компилятор и JVM. Казалось бы, прогнали компилятор через себя, работает, что еще надо? Но нет, при тестировании ставилась задача проверить все утверждения из спецификаций. Написано, что размер кода метода должен быть больше нуля и меньше 65536 — значит надо сделать методы длиной 0, 1, 65535 и 65536, и если 65536 машиной не отвергается — файлишь баг. Но это самай простая ситуация. А есть еще правила вывода типов переменных при слиянии ветвей исполнения, поведение volatile переменных (до появления нынешней memory model) и многие другие пыльные углы. И если бы тестировщики и разработчики относились к тестированию также как Вы, то Java никогда не стала бы столь популярной как сейчас.
А вообще, как говорится, «идея ничего не стоит». Вы бы сделали бы сначала хоть маленький шаг, хотя бы обрисовали проблематику. По мне, так основная проблема в отсутствии единого формализованого языка. У меня вот тоже была глобальная идея (ну не настолько глобальная как у вас) и я все удивлялся почему ее никто не разрабатывает. Постоянно мониторил интернет, а потом оказалось, что идея разрабатывается, но просто используют другие термины для описания, и я этих работ не находил.
И что вы собрались диагностировать, если дедлков гарантированно не будет возникать?
Действительно, правило неочевидное. Очевидное правило выглядит так:
— дедлок — это цикл на графе ресусов, чтобы не попадать в дедлок, надо избегать циклов.
Для этого:
— все блокируемые ресурсы организуются в нециклический ориентированный граф. Иными словами, определяется частичный порядок на множестве ресурсов.
— блокировка нескольких ресурсов допускается только в последовательности, сохраняющей этот порядок.
В оригинале, между прочим, «close to fifty years».
И кстати, начинать разработку тестов надо с вычитки спецификации на предмет ошибок, противоречий и недоговоренностей.
Спецификация — краеугольный камень разработки и тестирования. Видимо, усвоение этой аксиомы и есть то, что нас ждет завтра.