Ralph Johnson wrote:
I think the real answer is that there is no way to have a deadlock, because there is no way to wait. Programs can only busy-wait, so deadlock problems all get converted into starvation problems.
The first sentence is correct, but the second is wrong. It's wrong because there is no wait ;-) so even "busy-waiting" becomes meaningless. (Simulation) time, for example, does not advance in Croquet while a message is being executed. In this sense busy-waiting (here being the idea of performing computations until a measurable amount of time has passed) can't be done.
As for "deadlock problems all get converted into starvation problems" let's not forget that the problem we were looking at is over-constraint by definition. I *chose* to accept starvation mostly because this is the solution that is closest to the original. There are most certainly other (but more complex) solutions which could avoid starvation. The simplest one (which dodges the question of "and how exactly would that work") is to post requests for pairs of forks to the table and have the table implement a scheduling algorithm for the handing out forks.
Cheers, - Andreas