Concurrent Futures

Andreas Raab andreas.raab at gmx.de
Sun Oct 28 19:02:21 UTC 2007


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




More information about the Squeak-dev mailing list