3 ms·

I'm sure you can agree, that not having to worry about all kinds of races, contentions, deadlocks, wasting time on shotgun debugging, but still never really fee

I'm sure you can agree, that not having to worry about all kinds of races, contentions, deadlocks, wasting time on shotgun debugging, but still never really feeling like your program is reliable enough and about other "nice" things that come with shared memory multithreading is a huge advantage for any concurrent program.

wahern 9y ago
Multithreading is not synonymous with preemptive scheduling. That's an entirely different issue. A chain of promises or async/await functions is no better in this respect than so-called green threading, and in many cases is worse than a cooperatively scheduled framework that provides more explicit control over the points at which thread execution can switch. For example, a system built on stackful coroutines where thread execution only occurs at explicit resume points, or a simple message passing model where execution changes only at the point a message is transferred. These are basically continuation passing style, except importantly the _state_ of recursive function invocations is completely transparent to intermediate functions, without having to explicitly pass around state or annotate your function definitions. In other words, no different than how you'd write any other function. That's my point. The better _abstraction_ for all these things is a thread, no matter how you choose to schedule chunks of work or how you choose to implement things under the hood. A thread is just a construct that encompasses nested function invocations, and that construct is what promises and async/away emulate, except that that they leak implementation details and restrict the normal things functions do, like call other functions.
- zzzcpan 9y ago
  Here's the thing, if you can call functions that themselves can yield - you are in a shared memory multithreading model, where you can never guarantee for any function not to yield, so you have to use synchronization for that guarantee with all the same issues.
  - aidenn0 9y ago
    In a cooperative multi-threaded model you can only have data-races at function-call boundaries. For example: `x+=1` can never data-race.
    - ngrilly 9y ago
      Except if your programming language allows you to override the += operator.
      - aidenn0 9y ago
        You are proposing a situation where someone overrides += to specifically both call a blocking function and to not make it work correctly. I'm not saying it doesn't happen, but bad code is bad code regardless of your paradigm. Though I must admit I've not done cooperative multitasking in a language with operator overloading so I can't say whether or not this is a problem in practice.
        ngrilly 9y ago
        In can happen for example in Python with gevent.

wahern 9y ago

Multithreading is not synonymous with preemptive scheduling. That's an entirely different issue. A chain of promises or async/await functions is no better in this respect than so-called green threading, and in many cases is worse than a cooperatively scheduled framework that provides more explicit control over the points at which thread execution can switch. For example, a system built on stackful coroutines where thread execution only occurs at explicit resume points, or a simple message passing model where execution changes only at the point a message is transferred. These are basically continuation passing style, except importantly the _state_ of recursive function invocations is completely transparent to intermediate functions, without having to explicitly pass around state or annotate your function definitions. In other words, no different than how you'd write any other function. That's my point. The better _abstraction_ for all these things is a thread, no matter how you choose to schedule chunks of work or how you choose to implement things under the hood. A thread is just a construct that encompasses nested function invocations, and that construct is what promises and async/away emulate, except that that they leak implementation details and restrict the normal things functions do, like call other functions.

zzzcpan 9y ago
Here's the thing, if you can call functions that themselves can yield - you are in a shared memory multithreading model, where you can never guarantee for any function not to yield, so you have to use synchronization for that guarantee with all the same issues.
- aidenn0 9y ago
  In a cooperative multi-threaded model you can only have data-races at function-call boundaries. For example: `x+=1` can never data-race.
  - ngrilly 9y ago
    Except if your programming language allows you to override the += operator.
    - aidenn0 9y ago
      You are proposing a situation where someone overrides += to specifically both call a blocking function and to not make it work correctly. I'm not saying it doesn't happen, but bad code is bad code regardless of your paradigm. Though I must admit I've not done cooperative multitasking in a language with operator overloading so I can't say whether or not this is a problem in practice.
      - ngrilly 9y ago
        In can happen for example in Python with gevent.