Thanks for all of the replies.
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?
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??)
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.
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...)
I suppose there aren't really any answers to these points.
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.
--Ben
On 20 Nov 2003, at 07:30, Raphael Collet wrote:
> Hi Ben,
>
>> A question has occurred to me whilst reading the Concepts Techniques
>> and Models book...
>
> (snip snip)
>
>> But isn't there observable nondeterminism in the declarative
>> concurrent
>> subset of Oz by exactly the same argument:
>>
>> declare C
>> thread
>> C=1
>> end
>> thread
>> C=2
>> end
>>
>> ... with this example you cannot tell in advance which value C will be
>> bound to. Certainly the other binding attempt will fail, but isn't
>> this
>> observable nondeterminism nonetheless?
>>
>> I expect there's a flaw in my argument somewhere - but I can't see
>> it...
>
> The flaw is that you assume that your program terminates normally. But
> the binding that fails makes the whole computation fail! All you can
> observe is a failure, actually. The final store contains no consistent
> information.
>
> In the stateful case, your program successfully terminates. The final
> store of your program mentions a cell that contains 1 or 2.
>
>
> 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.
-
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.