throwTo semantics

[Roman Cheplyaka]

* Bertram Felgenhauer <bertram.felgenhauer at googlemail.com> [2013-07-28 17:57:04+0200]
> 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.

Thanks Bertram, this makes perfect sense. I wonder if the docs should be
updated to clarify this?

Roman