On 29/10/2007, Andreas Raab andreas.raab@gmx.de wrote:
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.
I'm not really sure, that GC example is good parallel for 'automatic deadlock-free'. What prevents me (or anyone) to write a deadlocks like following: [ self grabFork ] whileFalse: ["do nothing " ]
There is no such language (except from ones, which don't have loops/branches) which prevents from writing this. And the example above is 'busy waiting' which is even worser than waiting using semaphores, because it wasting CPU resources for evaluating same expression until some state will change by external entity. So, unless a developer writes a better code, we will have same issues. As for GC - you have automatic memory management instead of manual. But there's no automatic algorithm management and never will be , given any language :)
Cheers,
- Andreas