On 12/05/2011 18:24, dm-list-haskell-c...@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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
