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
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
* 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.
Thanks Bertram, this makes perfect sense. I wonder if the docs should be updated to clarify this? Roman
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
participants (3)
-
Bertram Felgenhauer -
Roman Cheplyaka -
Simon Marlow