Concurrent Futures
Andreas Raab
andreas.raab at gmx.de
Mon Oct 29 18:46:02 UTC 2007
Igor Stasenko wrote:
> A small correction: the problem of dining philosophers are about how
> to share a limited resources (forks) among consumers (philosophers)
> effectively to prevent starvation of any of them. And your solution
> are based on 'nice' behavior of philosopher, which drops the first
> fork, when he's unable to obtain second one.
Right. I was trying to keep things simple for the benefit of
illustrating the concurrency aspects only. If you look at the full
version in E it addresses that and probably half a dozen of problems
that none of us has ever thought about (these guys really are amongst
the smartest people that I've ever met).
> A 'bad' behavior is much more probable , because most developers tend
> writing a code in simple imperative style, like: do this, after done
> it, do that. And understanding that they code can contain problems
> (deadlocks or whatever) comes in mind only after problem shows itself.
> And considering that deadlocks are very hard to track and reproduce
> they'll never know what may cause it :)
Indeed. However, this is where E really helps you. Everything you can
express in E is by definition deadlock-free (in the classic sense) so
you stop worrying about these things and focus more on the solution to
the problem at hand. Not so different to manual memory management where
before the advent of GC you always had that nagging feeling in the back
of your head saying "and who's gonna know when and where to free that
reference?". The point is that as GC issues become tractable by not
causing a segfault, concurrency issues become tractable by not having
your system come to a screaching halt every time something goes wrong.
Cheers,
- Andreas
More information about the Squeak-dev
mailing list
|