|Version 24 (modified by simonmar@…, 7 years ago)|
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
what is provided
At least the following interface will be provided
- Control.Concurrent.MVar - everything except addMVarFinalizer
- Control.Concurrent - ThreadId?,myThreadId,forkIO,yield,threadWaitRead,threadWaitWrite,threadDelay
the FFI must be able to handle 'concurrent nonrentrant' imports, but not necessarily 'concurrent reentrant' ones.
- if any haskell thread is runnable then at least one thread will be running.
- foreign calls marked 'concurrent' will not interfere will the above rule.
Additionally, we have a fairness property of MVars:
- A thread blocked on an MVar will eventually run, provided there are no other threads holding the MVar indefinitely.
This means that MVar blocking must be implemented in a fair way, eg. a FIFO of blocked threads.
initial proposal is here:
Alternate, simpler proposal: full memory barrier at every putMVar and takeMVar.
perhaps a better phrasing of the first proposal exists, in practice, from a users point of view, it would be hard to tell the difference between the two models, but we should say something concrete on the matter.
Misc library stuff
yield is guarenteed to choose an alternate thread if another one exists and is runnable.
threadDelay guarentees the thread will wait as long as its argument at a minimum. it may be blocked for longer.
 may be moved to another module (Control.Concurrent.IO?) , routines working on Handles should be added too.
Optional extensions to basic standard
These are optional extensions a compiler may implement. In some implementations they may entail a run-time cost to non-concurrent code or a compiler might need a special option to enable them. However, A compiler is not required to provide more than one concurrency model as long as it can meet the requirements of the standard and any options it claims to support.
If a compiler documents that it supports one of the following options, then it must adhere to the rules of that option as well.
Optional Feature 1 - Preemption
The standard only requires a progress guarentee, that a thread is always running, making progress. If an implementation supports context switching during arbitrary computations and meets the stronger fairness guarentee below, then it can be said to support the 'Preemption' option.
- no starvation
new library calls provided
- mergeIO, nmergeIO
Optional Feature 2 - OS threads
The implementation additionally allows the following:
- foreign exported functions, and function pointers created by foreign import "wrapper", can be invoked from multiple OS threads
- bound threads: forkOS, isCurrentThreadBound, runInBoundThread, runInUnboundThread
- concurrent/reentrant foreign calls are supported