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
|