Changes between Version 33 and Version 34 of Concurrency


Ignore:
Timestamp:
Apr 13, 2006 2:54:42 PM (8 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