Dimitry SibiryakovАнатоЛойТеперь допускаем, что...
....система построена без использования естественного интеллекта. Ну и кто при этом ССЗБ?..

Дмитрий, поумерьте язвительности и грубости, пожалуйста, это не ваш личный блог...
Теперь таки представьте, что возможность чуваков хаотично метаться между ресурсами дана нам как требование, то есть свыше (см. стартовый топик). (Например, будем иметь 50 исков на дню за ограничение свободы и прочую дискриминацию, или, если уж шутливый тон не воспринимается, считаем что мы пишем интеграционный модулёк к какой-то большой и сложной системе, где не можем себе позволить выстраивать запросы в очередь, поскольку мы не столовая, а кафе, в которой 99% заказов - из одного блюда). Что дальше?

vromanovДедлки возникают по следующей причне. У вакс есть два объекта A и Б. Предположим, это количество средств на счету покупателя и количество товара Х.
Дедлок возникнет если одна часть вашего приложения, сначала залочит объект А, вторая объект Б. А потом первая попытается получить доступ к Б а вторая к А. Вот они и будут ждать друг-друга.

Я вас понял, вы меня - нет. Ваше описание дедлока мне понятно. Она - суть простейшей модели дедлока. Я привёл пример из жизни, работающий именно по этой модели, только, похоже, вы за множеством дедлоков в моём примере этот самый дедлок то и не заметили.

Мой пример работает по вашей модели:
Вместо объекта А - компот, вместо объекта Б - пирожное.
Два чувака (две части нашего приложения) покупают подружкам пирожное с компотом , но один сначала пошёл налево за пирожным, второй направо за компотом (лочат объекты А и Б).
Когда каждый из них пришёл за вторым блюдом (попытались получить доступ к Б и А), оказалось что второго блюда для них нет. Каждому вернуться к барышням без второго блюда гордость не позволяет, новые компоты с пирожными не приносят.
"Вот они и будут ждать друг-друга", ожидая, кто вернёт своё блюдо на полку первым :).

vromanovАнатоЛой поскольку мы не столовая, а кафе, в которой 99% заказов - из одного блюда). Что дальше?
не вижу тут причны для дедлока.

Конкретно данная фраза - про неэффективность организации потока с подносами.
Причина для дедлока надеюсь внятно описана выше на ваших объектах А и Б.

vromanovОтсутвие таких проблем решается дизайном.
Также для уменшения врероятности любых - уменьшение зацепления.
Т.е. если у вас етсь транзакции делайте их короткими.
Например, если кто-то выбрал товар, то не надо лочить эту строчку, а просто зарезервируйте его на некоторое количество времени и осводите транзакцию.
По-моему, никто из участников не сомневается, что проблема дедлока решается - если нет требований/ограничений для реализации того или иного алгоритма. Мы с первом поста говорим о том, есть ли такие функциональные требований (читай "требования из среды") , что дедлоки таки будут случаться (читай "нельзя организовать обработку ресурсов таким образом, что мы полностью избежим ситуаций с возникновением дедлока, и не придётся придумывать тайм-ауты или "внешних наблюдателей" или доп. обработку, прежде чем заблокировать ресурс")). Я привёл пример, когда упорядочивание ресурсов (последовательность блюд на вдоль реек с подносами) и упорядочивание потребителей ресурсов (посетителей кафе в очереди с подносами) не удовлетворяет функциональным требованиям (посетители вправе в произвольном порядке подходить к блюдам).

П.С.: В топике не хватает топик-стартера для оценки достигнутых результатов :)

Dimitry SibiryakovАнатоЛойТеперь таки представьте, что возможность чуваков хаотично метаться между
ресурсами дана нам как требование, то есть свыше (см. стартовый топик).

Тогда достаточно устранить второе условие дедлока и отпускать занятый ресурс прежде чем
вставать в очередь к следующему.

К сожалению, я не понял, что это будет обозначать в моём примере...
Отдавать компот/пирожное барышням, прежде чем идти за пирожным/компотом?
Или возвращать компот/пирожное на полку?
Поясните, пожалуйста.

vadiminfoАнатоЛойП.С.: В топике не хватает топик-стартера для оценки достигнутых результатов :)
Ну, возможно, следует достигнуть еще больших результатов, и чтобы там было именно теоретическое что-то (вопрос то теоретический по мнению ТС). Например, теорема с формальным доказательством. Возможно, нескольких примеров ему все еще недостаочно.
Согласен, все дружно без целей постебались. Разрешите сворачиваться ? .

Dimitry SibiryakovАнатоЛойК сожалению, я не понял, что это будет обозначать в моём примере...

Взял компот, перелил себе на поднос, вернул на полку. Взял пирожное, скопировал себе на
поднос, вернул на полку. Теперь у тебя есть обои, можешь идти к барышням.

В моём примере я не могу "скопировать" пирожное или компот. Выше предложение по реализации нереализуемо.

Dimitry SibiryakovАнатоЛойВ моём примере я не могу "скопировать" пирожное или компот.

Совесть не даёт? Ню-ню...

В таком случае твоё доказательство неизбежности дедлоков звучит как "я не могу иначе". К
счастью, не все люди так религиозны.


У меня впечатление, что мы все о разном.

Dimitry SibiryakovДеадлоки это артефакт реализации конкретной СУБД. Никакой общей теории для них нет.

Дмитрий, в каких известных вам СУБД такого артефакта нет?