Changes between Version 30 and Version 31 of Concurrency


Ignore:
Timestamp:
Apr 13, 2006 1:34:27 PM (9 years ago)
Author:
simonmar@…
Comment:

Add outstanding issues

Legend:

Unmodified
Added
Removed
Modified
  • Concurrency

    v30 v31  
    3535
    3636------------------------
     37== Outstanding issues ==
     38
     39There follows a list of issues on which decisions are still to be
     40made.  A numbered item, eg. 1.2, indicates a question, an item ending
     41in a letter, eg. 1.2.a, indicates a possible choice for question 1.2.
     42
     43=== 1. Cooperative or preemptive concurrency? ===
     44
     45'''1.a.''' The spec requires cooperative concurrency, preemption is
     46allowed as an extension.  Both would be specified precisely in
     47terms of what progress and fairness guarantees the programmer can
     48expect.
     49
     50'''Pros'''
     51 * Allows many more implementations, including Hugs (although Hugs
     52   needs to be updated to handle concurrent and
     53   concurrent/reentrant foreign calls, and non-blocking I/O).
     54 * Preemption isn't always required; a common case is an
     55   application that relies on concurrency for I/O multiplexing,
     56   where most threads are usually blocked.
     57 * Cooperative systems can be faster, and are simpler to implement
     58   (see state threads reference).
     59
     60'''Cons'''
     61 * Portability problems: if a programmer develops a concurrent
     62   application on a preemptive system, there is no guarantee that
     63   it will work as expected on a cooperative system, and the
     64   compiler/runtime can give no useful feedback.
     65 * Need to specify which operations are "yield points" in library
     66   documentation.
     67 * Long-running pure code must be refactored into the IO monad so
     68   that explicit yield points can be inserted.
     69
     70[[BR]]
     71'''1.b.''' Preemption is required by the spec.
     72
     73'''Pros'''
     74 * Simpler from the programmer's point of view: no yield, no
     75   worrying about latency.  "write code as if the current
     76   thread is the only one.".
     77
     78'''Cons'''
     79 * Imposes significant implementation constraints.  Essentially
     80   only GHC and YHC would be able to implement it.  JHC has no
     81   concept of thunks, which is a barrier to implementing general
     82   preemption.
     83 * Even in a preemptive system, deadlocks are easy to program, and
     84   arbitrary starvation can result from laziness: evaluating
     85   arbitrary expressions while holding an MVar can prevent other
     86   threads from running.  The fact that we therefore require seq
     87   and possibly deepSeq is disturbing, as is the notion that the
     88   programmer must think about "what is evaluated" when
     89   programming concurrent code.
     90
     91[[BR]]
     92'''1.b.1.'''  Include thread priorities or not?
     93
     94'''Pros'''
     95 * Some applications require it
     96 * It affects the fairness/progress guarantees, including the
     97   possibility of priorities from the outset may be simpler.
     98
     99'''Cons'''
     100 * Hard to implement, no implementations yet.
     101
     102
     103=== 2. Syntax for foreign call annoatations. ===
     104
     105'''2.1.''' choices for concurrent calls:
     106
     107'''2.1.a.''' we annotate concurrent calls with
     108
     109  '''a.''' concurrent[[BR]]
     110  '''b.''' mayblock[[BR]]
     111  '''c.''' mightblock[[BR]]
     112  '''d.''' blocks[[BR]]
     113  '''e.''' longrunning[[BR]]
     114
     115  '''Rationale''' for using the term "block": blocking is the main
     116  reason for wanting concurrent calls.  Concurrent calls allow the
     117  progress guarantee to be retained in the presence of a blocking
     118  foreign call.  A foreign call that just takes a long time is still
     119  making progress.
     120
     121  '''Rationale''' for not using the term "block": the fact that the
     122  call blocks is immaterial, the property we want to provide is that
     123  it doesn't impede progress of other Haskell threads.  A long-running
     124  call is indistinguishable from a blocked call in terms of the
     125  progress of other threads.
     126
     127  We often don't know whether a library call will block or not (it
     128  isn't documented), whereas saying a call should run concurrently
     129  with other threads is a choice the programmer can reasonably make.
     130
     131'''2.1.b.''' we annotate non concurrent calls:
     132
     133  '''Rationale''' for annotating the non-concurrent calls: this is a
     134  performance issue.  It is always correct to make a concurrent call,
     135  but it might be more efficient to make a non-concurrent call if the
     136  call does not block.  An implementation might implement ''all''
     137  calls as concurrent, for simplicity.
     138
     139  Against: John Meacham says "The FFI is inherently unsafe. We do not
     140  need to coddle the programer who is writing raw FFI code."
     141
     142  '''a.''' nonconcurrent[[BR]]
     143  '''b.''' noblock[[BR]]
     144  '''c.''' returnsquickly[[BR]]
     145  '''d.''' fast[[BR]]
     146  '''e.''' quick[[BR]]
     147
     148[[BR]]
     149'''2.2.''' choices for non-reentrant calls:
     150
     151  '''a.''' nonreentrant[[BR]]
     152  '''b.''' nocallback
     153
     154  '''Rationale''' for annotating the non-reentrant calls, as opposed
     155  to the reentrant ones: we want the "safe" option to be the default
     156  (as in the FFI spec).
     157
     158[[BR]]   
     159'''2.3.''' should we annotate foreign calls according to whether they need
     160to access thread-local state (TLS) or not?
     161
     162'''Pros'''
     163 * a call that doesn't need access to thread-local state, called from a bound thread, can be executed much more quickly on an implementation that doesn't run the Haskell thread directly on the bound OS thread, because it doesn't need to context switch.
     164
     165'''Cons'''
     166 * libraries that require TLS, eg. OpenGL, often have many fast TLS-using functions.  So implementations that need the no-TLS annotation in order to get good performance, will probably still get poor performance from libraries that need TLS anyway.
     167
     168------------------------
    37169== References ==
    38170