Roman Cheplyaka | 28 Jul 15:36 2013

throwTo semantics

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 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

?

Roman
Bertram Felgenhauer | 28 Jul 17:57 2013

Re: throwTo semantics

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.

(Continue reading)

Roman Cheplyaka | 28 Jul 18:47 2013

Re: throwTo semantics

* 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.
(Continue reading)

Simon Marlow | 13 Aug 16:54 2013
Picon

Re: throwTo semantics

On 28/07/13 14:36, 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 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.

Perhaps this needs to be clarified.  The extra information is: if a 
thread's next operation is a throwTo, then it may either receive an 
exception from another thread *or* perform the throwTo, but not both. 
Informally, there's no state of the system in which the exception is "in 
flight": it has either been delivered or not.

Cheers,
	Simon
Bertram Felgenhauer | 10 Sep 22:44 2013

Re: throwTo semantics

Simon Marlow wrote:
> On 28/07/13 14:36, 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 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.
> 
> Perhaps this needs to be clarified.

How about the attached patch?

Best regards,

Bertram
_______________________________________________
(Continue reading)


Gmane