Changes between Version 33 and Version 34 of Concurrency


Ignore:
Timestamp:
Apr 13, 2006 2:54:42 PM (9 years ago)
Author:
simonmar@…
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Concurrency

    v33 v34  
    7878'''Pros'''
    7979 * Simpler from the programmer's point of view: no yield, no
    80    worrying about latency.  "write a thread as if the current
     80   worrying about latency.  "write code as if the current
    8181   thread is the only one.".
    8282
     
    106106
    107107
    108 === 2. nomenclature for foreign call annoatations. ===
     108=== 2. Syntax for foreign call annoatations. ===
    109109
    110110'''2.1.''' choices for concurrent calls:
     
    112112'''2.1.a.''' we annotate concurrent calls:
    113113
    114   a. concurrent
    115   b. mayblock
    116   c. mightblock
    117   d. blocks
    118   e. longrunning
    119 
    120 '''Rationale''' for using the term "block": blocking is the main
    121 reason for wanting concurrent calls.  Concurrent calls allow
    122 the progress guarantee to be retained in the presence of a
    123 blocking foreign call.  A foreign call that just takes a long
    124 time is still making progress.
    125 
    126 '''Rationale''' for not using the term "block": the fact that the
    127 call blocks is immaterial, the property we want to provide is
    128 that it doesn't impede progress of other Haskell threads.  A
    129 long-running call is indistinguishable from a blocked call in
    130 terms of the progress of other threads.
    131 
    132 We often don't know whether a library call will block or not
    133 (it isn't documented), whereas saying a call should run
    134 concurrently with other threads is a choice the programmer can
    135 reasonably make.
     114  '''a.''' concurrent[[BR]]
     115  '''b.''' mayblock[[BR]]
     116  '''c.''' mightblock[[BR]]
     117  '''d.''' blocks[[BR]]
     118  '''e.''' longrunning[[BR]]
     119
     120  '''Rationale''' for using the term "block": blocking is the main
     121  reason for wanting concurrent calls.  Concurrent calls allow
     122  the progress guarantee to be retained in the presence of a
     123  blocking foreign call.  A foreign call that just takes a long
     124  time is still making progress.
     125
     126  '''Rationale''' for not using the term "block": the fact that the
     127  call blocks is immaterial, the property we want to provide is
     128  that it doesn't impede progress of other Haskell threads.  A
     129  long-running call is indistinguishable from a blocked call in
     130  terms of the progress of other threads.
     131
     132  We often don't know whether a library call will block or not
     133  (it isn't documented), whereas saying a call should run
     134  concurrently with other threads is a choice the programmer can
     135  reasonably make.
    136136
    137137'''2.1.b.''' we annotate non concurrent calls:
    138138
    139 '''Rationale''' for annotating the non-concurrent calls: this is a
    140 performance issue.  It is always correct to make a concurrent
    141 call, but it might be more efficient to make a non-concurrent
    142 call if the call does not block.  An implementation might
    143 implement *all* calls as concurrent, for simplicity.
    144 
    145 Against: John Meacham says "The FFI is inherently unsafe. We
    146 do not need to coddle the programer who is writing raw FFI
    147 code."
    148 
    149   a. nonconcurrent
    150   b. noblock
    151   c. returnsquickly
    152   d. fast
    153   e. quick
     139  '''Rationale''' for annotating the non-concurrent calls: this is a
     140  performance issue.  It is always correct to make a concurrent
     141  call, but it might be more efficient to make a non-concurrent
     142  call if the call does not block.  An implementation might
     143  implement *all* calls as concurrent, for simplicity.
     144 
     145  Against: John Meacham says "The FFI is inherently unsafe. We
     146  do not need to coddle the programer who is writing raw FFI
     147  code."
     148
     149  '''a.''' nonconcurrent[[BR]]
     150  '''b.''' noblock[[BR]]
     151  '''c.''' returnsquickly[[BR]]
     152  '''d.''' fast[[BR]]
     153  '''e.''' quick[[BR]]
    154154
    155155'''2.2.''' choices for non-reentrant calls:
    156156
    157   a. nonreentrant
    158   b. nocallback
     157  '''a.''' nonreentrant[[BR]]
     158  '''b.''' nocallback
    159159       
    160 '''Rationale''' for annotating the non-reentrant calls, as opposed
    161 to the reentrant ones: we want the "safe" option to be the
    162 default (as in the FFI spec).
     160  '''Rationale''' for annotating the non-reentrant calls, as opposed
     161  to the reentrant ones: we want the "safe" option to be the
     162  default (as in the FFI spec).
    163163   
    164164'''2.3.''' should we annotate foreign calls according to whether they need
    165165to access thread-local state (TLS) or not?
    166166
    167 In favour: a call that doesn't need access to thread-local state,
    168 called from a bound thread, can be executed much more quickly on
    169 an implementation that doesn't run the Haskell thread directly on
    170 the bound OS thread, because it doesn't need to context switch.
    171 
    172 Against: libraries that require TLS, eg. OpenGL, often have many
    173 fast TLS-using functions.  So implementations that need the no-TLS
    174 annotation in order to get good performance, will probably still
    175 get poor performance from libraries that need TLS anyway.
     167'''Pros'''
     168
     169 * 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.
     170
     171'''Cons'''
     172 
     173 * 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.
    176174
    177175