On 12/05/2011 18:24, dm-list-haskell-cafe@scs.stanford.edu wrote:
At Thu, 12 May 2011 16:45:02 +0100, Simon Marlow wrote:
There are no locks here, thanks to the message-passing implementation we use for throwTo between processors.
Okay, that sounds good. So then there is no guarantee about ordering of throwTo exceptions? That seems like a good thing since there are other mechanisms for synchronization.
What kind of ordering guarantee did you have in mind? We do guarantee that in
throwTo t e1 throwTo t e2
Thread t will receive e1 before e2 (obviously, because throwTo is synchronous and only returns when the exception has been raised). ... Pending exceptions are processed in LIFO order (for no good reason other than performance)...
I mean, suppose you have three CPUs, A, B, and C running threads ta, tb, and tc. Then should the following order of events be permitted?
A B C throwTo tc e1 throwTo tb e2 catch e2 poke p x peek p (sees x) catch e1
I would argue that this is just fine, that one should rely on MVars if one cares about ordering. But I'm not sure what "Pending exceptions are processed in LIFO order" means in the presence of relaxed memory consistency.
Oh, that can't happen. A's first throwTo only returns when the exception has been raised in C - throwTo is like a synchronous communication in this sense. We went to-and-fro on this aspect of the throwTo design a few times. The synchronous semantics for throwTo tends to be more useful for the programmer, but is harder to implement. If you want asynchronous throwTo, you can always get it with forkIO.throwTo. As far as memory consistency goes, we claim to provide sequential consistency for IORef and IOArray operations, but not for peeks and pokes.
The reason I'm asking is that I want to make sure I never end up having to pay the overhead of an MFENCE instruction or equivalent every time I use unmaskAsyncExceptions#...
Right, I don't think that should be necessary. Cheers, Simon