I don't like runAtomically either, because once again it assumes a global lock. This is fine for GHC or Hugs or NHC on single processors, but it would be a pain if you had multiple processors. You can't avoid locking between processors altogether of course; atomicModifyPVars and the unsafePerformIO hack I just posted require data to be updated consistently (you don't want the same unsafePerformIO being evaluated twice). However that is not so bad because the locking is only on particular bits of data; it's reasonable that access to particular thunks or PVars will be "owned" by one processor or another, so that if two processors are working on independent bits of state they can chug along perfectly happily without locking each other, and only need to talk when one processor wants to get at a bit of state owned by another. Although Alastair suggests compilers might try to spot when runAtomically can be used safely without stopping all but one processor, I think analysis of IO actions to check for potential conflicts might be even harder than getting Hugs to run Haskell finalizers 8-) It would require region analysis and probably worse. However we don't really need to discuss this anyway, since I don't think either runAtomically or atomicallyModifyIORef need to be in the FFI standard. I'm quite happy to leave this open.