On 13-Jun-1998, Peter White <peter@galois> wrote:
>
> I wonder if there is another issue relating potential nondeterminism
> of exceptions to the independence of threads. It is supposed to be
> the case that two different threads have behavioral independence, so
> that an implementation could run the threads in any order, interleave
> their execution in any way, and the two threads would still give the
> same results.
Well, that depends on whether you want parallelism, or concurrency.
If you just want parallelism, i.e. you're just using threads to
improve performance, then yes, the order of interleaving should
not affect the results. But if you're using concurrency, then this
isn't necessarily true -- the order of interleaving may affect the
results, and this may be exactly what you want.
> Take the case of a heap overflow exception.
As noted earlier, things like heap overflow, and stack overflow
are different from other kinds of exceptions. They can't be modelled
using the domain-theoretic semantics. Rather, they reflect the failure
of the operational semantics to accurately reflect the domain-theoretic
semantics. Thus the treatment of these exceptions may need to be
different to the treatment of ordinary exceptions.
In particular, instead of
data MaybeException a = OK a | GotException (NDSet Exception)
ndset_catch :: a -> MaybeException a
you need something like
data ResourceFailure = StackOverFlow | HeapOverFlow | ...
data MaybeResourceFailure a = Computed (MaybeException a)
| Failed ResourceFailure
ndset_catch_all :: a -> NDSet MaybeFailure
Timeouts may also be considered as resource failures. Interrupt
handlers could also be considered as exceptions or resource failures,
but I think is probably nicer to consider them as forms of
concurrency.
> Suppose the two threads
> demand more memory than is provided in the computer. One of the two
> threads will hit a heap overflow exception. In order to have the
> implementation guarantee thread independence, the heap overflow of
> one thread cannot depend upon the memory consumption of the other
> thread. If there is a dependence, then one thread can determine the
> behaviour of the other thread by choosing to consume memory on the
> heap or not.
If you're worried about covert communication channels, then yes, you
have to worry about things like this. But generally covert communication
channels are not an issue. So in general it's enough to say that
whether or not you get a HeapOverflow resource failure is nondeterministic.
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
