|Version 7 (modified by simonmar@…, 8 years ago) (diff)|
on the wiki:
- The Control.Concurrency module
Papers and other docs:
- Concurrent Haskell (the original paper, including a semantics)
- Extending the Haskell FFI with Concurrency (a specification of the interaction between concurrency and the FFI, with a semantics)
- A Draft report addendum (a shorter version of the above paper).
- Software Transactional Memory
- Vital for some modern applications and large applications commonly require it.
- Stable MVar implementation is well understood and tested.
- Imposes non trivial implementation constraints.
- Providing a 'select' and non-blocking IO would be enough to allow people to implement something like it themselves in haskell and are provided by most systems as primitives.
- Things like the 'poor man's concurrency monad' can achieve some of the benefits
- Standardise on Concurrent Haskell without STM. It is our view that even in the presence of STM, MVars offer functionality that is distinct from STM and separately useful, so this leaves room for growth.
- Use the semantics from Extending the Haskell FFI with Concurrency
- Standardise a way to write thread-safe libraries that work with implementations that don't provide full concurrency support.
- Decide whether the Haskell' report includes Concurrency (with a separate NoConcurrency addendum to specify how implementations without concurrency behave), or whether Concurrency is specified in a separate addendum.
- Decide how much pre-emption is acceptable, and figure out how to specify this.
- Require bound thread support, or make it optional? (YHC has concurrency with non-blocking foreign calls, but doesn't have bound threads as yet.)
In order to write library code that is thread-safe when run in a multi-threaded environment, two things are needed:
- a way to protect mutable state against race conditions
- a way to declare that foreign calls are blocking
For (1), we have two choices:
- Provide MVars. A non-concurrent implementation might implement them in terms of IORef, for example.
- Provide STM. Not entirely trivial to implement, even in a single-threaded implementation, because exceptions have to abort a transaction.
For (2), one option is ForeignBlocking.
There are several levels of concurrency support which require sucessivly more implementation support and imply more implementation overhead.
The report says nothing about concurrency at all
Enough is specified to allow people to write completley portable programs and libraries that while they may not depend on concurrency, will not break in the presence of it.
This would entail
- A standardized MVar-like structure.
- something along the lines of ForeignBlocking
This would allow concurrency needing programs to be written, but perhaps not as transparently as it curently is with GHC. This would include everything needed to write concurrent programs without anything that would imply a run-time or implementation overhead in the non-concurrent case.