Skip to content

Conversation

@jorisdral
Copy link
Contributor

First stab at #112

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementations in this module are based on Data.IORef and GHC.IORef from base-4.19.0.0

Comment on lines +63 to +72
instance MonadIORef m => MonadIORef (ReaderT r m) where
type IORef (ReaderT r m) = IORef m
newIORef = lift . newIORef
readIORef = lift . readIORef
writeIORef = lift .: writeIORef
modifyIORef = lift .: modifyIORef
modifyIORef' = lift .: modifyIORef'
atomicModifyIORef = lift .: atomicModifyIORef
atomicModifyIORef' = lift .: atomicModifyIORef'
atomicWriteIORef = lift .: atomicWriteIORef
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be moved to io-classes-mtl?

Comment on lines +37 to +40
atomicModifyIORef2Lazy :: IORef (IOSim s) a -> (a -> (a,b)) -> IOSim s (a, (a, b))
atomicModifyIORef2Lazy (IORef (STRef r#)) f = stToIO $
ST (\s -> case atomicModifyMutVar2# r# f s of
(# s', old, res #) -> (# s', (old, res) #))
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since IORefs are STRefs, we can copy the code from base. However, this is probably overkill -- @coot, do you have pointers for how I should proceed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, these implementations might change slightly between GHC releases. I see that GHA is failing because GHCs before 9.8 don't have access to an atomicSwapMutVar# function

@jorisdral jorisdral requested a review from coot February 17, 2024 18:22
Copy link
Contributor

@dcoutts dcoutts left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The iosim implementations could be simpler because there's no genuine concurrency, even in the POR case. No primitive can be interrupted. In particular anything lifted using stToIO is a single LiftST action in the interpreter. So that means "atomic" modify can be implemented just as a read and write, wrapped in stToIO.

@dcoutts
Copy link
Contributor

dcoutts commented Feb 19, 2024

Arguably, these should be implemented as "proper" simulation primitives for the benefit of the POR case. Otherwise the POR interpreter cannot see that they might be interesting to reorder.

@jorisdral jorisdral self-assigned this Mar 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants