throwTo semantics

[Bertram Felgenhauer]

Roman Cheplyaka wrote:
> The documentation for throwTo says:
> 
>   throwTo does not return until the exception has been raised in the
>   target thread. The calling thread can thus be certain that the target
>   thread has received the exception. This is a useful property to know
>   when dealing with race conditions: eg. if there are two threads that
>   can kill each other, it is guaranteed that only one of the threads
>   will get to kill the other. 
> 
> I don't see how the last sentense follows.

I agree that it does not follow logically, at least I don't see how.
It is an additional guarantee that the implementation provides.

> I understood it so that the implication
> 
>   throwTo has returned => exception has been delivered
> 
> is true, but not the reverse. If my understanding is correct, then both
> exceptions could be delivered without any of throwTos returning.
> 
> Or is it true that
> 
>   throwTo has returned <=> exception has been delivered

Yes, that's true, in the sense that if and only if the exception
has been delivered, the thread is ready to run (i.e., not blocked),
to continue right after the throwTo.

The implication from left to right does not mean that the thread
ever gets a chance to run again. The program may terminate, or
the thread may receive another exception in the meantime. The
latter can be prevented by masking exceptions.

I hope that makes sense.

Bertram