Ben wrote:
> The answer seems to be that it's the fact that unification can raise an
> exception which introduces the nondeterminism. That seems to make
> sense.... but isn't nondeterminism actually creeping in purely from the
> fact that either thread is allowed to bind the same unbound variable -
> whichever thread gets there first?
If only one thread binds a given variable, you won't have problems with
that variable. And you know what? This is the most common situation in
our programs.
> I'm left feeling slightly uneasy about a couple of things:
> 1) Since it's the unification procedure which we're talking about it
> basically means that it's not possible to use a truly deterministic
> concurrent subset of Oz - (unless we wrote a new unification procedure
> maybe??)
This is truly deterministic. In the declarative model, a program either
always fails, or never fails. Always failing is deterministic.
> 2) The failure of the program could occur at any time - there is no
> way in advance I can tell whether one of my threads will in the future
> attempt to do such an invalid unification - in exactly the same way I
> can't necessarily tell whether any threads calculation will terminate.
It's only the case if you write random programs ;-) The programmer
KNOWS what his/her threads are supposed to do and not to do.
> What this means is that it could appear that my program was working
> successfully, and giving one particular answer - and at any point I
> would never know whether it was really just due to "luck"
> (non-determinism) that I had arrived at that answer - I would never
> know if my program was just about to fail with an invalid unification -
> which might have succeeded had the luck/non-determinism gone the other
> way. (Obviously the longer I wait the more certain I'll get - but I can
> never be absolutely certain that the program would behave the same way
> if I ran it again...)
The declarative model of the book is concurrent deterministic.
Declarative programs don't change their mind ;-) If your program
terminates once successfully with an answer (possibly a failure),
running it again with the same input will give you exactly the same
answer. Otherwise, you're no longer in the declarative model.
> I suppose there aren't really any answers to these points.
Read carefully the book. You can find answers to your questions in it!
> The reason I've been thinking about these issues is that I've been
> trying to understand what the practical benefits (and limitations) of
> using a model like the declarative concurrent model would be. I suppose
> that in practice the discipline imposed by that model is useful.
You can apply the techniques coming from the declarative model in lots
of situations. You can write highly interactive programs with lots of
concurrency, where 90% of the code is declarative! And that part of the
program is usually easier to test and check for correctness. You can't
do that in Java.
Cheers,
raph
-
Please send submissions to users@mozart-oz.org
and administriva mail to users-request@mozart-oz.org.
The Mozart Oz web site is at http://www.mozart-oz.org/.
Please send bug reports to bugs@mozart-oz.org.