10 ms·

If you are using explicit blocking, share data between threads and have not run into deadlocks then your application is trivial (which is great if it solves you

by jupp0r 3y ago

If you are using explicit blocking, share data between threads and have not run into deadlocks then your application is trivial (which is great if it solves your problem).

riku_iki 3y ago
Could you explain how sharing data between threads is different in async programming and blocking programming?
- jupp0r 3y ago
  You can minimize sharing data between threads because it's easier to have data affinity with threads (ie only thread A will read or write to a piece of data). You can still access that data from multiple modules because the whole thread is never blocked waiting for IO (because of async). An extreme example is nodejs, where you only have one thread, can concurrently do thousands of things and never have to coordinate (ie via mutexes) data access.
  - riku_iki 3y ago
    that may be true if you are Ok to have only one thread and not utilize parallelism.
    - jupp0r 3y ago
      It's not either or, you can combine the two. I've worked on a system that did real time audio mixing for 10000s of concurrent connections, utilizing >50 cores, mostly with one thread each. Each thread had thread-local data, was receiving/sending audio packets to hundreds/thousands of different IP addresses just fine without worrying about mutexes at all. Try that with tens of thousands of actual OS threads and the associated scheduling overhead. Having data affinity to cores is also great for cache hit rates. Here is part of the C++ runtime this is based on: https://github.com/goto-opensource/asyncly https://github.com/goto-opensource/asyncly. I was the principal author of it when it was created (before it was open sourced).
      - riku_iki 3y ago
        > Each thread had thread-local data, was receiving/sending audio packets to hundreds/thousands of different IP addresses just fine without worrying about mutexes at all. it doesn't sound they really sharing data with each other, it looks like your logic is well lineralizable and data localized, and you can't implement access to some global hashmap in that way for example. > Try that with tens of thousands of actual OS threads and the associated scheduling overhead. I run this(10k threads blocked by DB access) in prod and it works fine for my needs. There are lots of statements in internet about overhead, but not much benchmarks how large this overhead is. > Here is part of the C++ runtime this is based on yeah, I need one runtime on top of another runtime, with unknown quality, support, longevity and number of gotchas.
        jupp0r 3y ago
        > it doesn't sound they really sharing data with each other, it looks like your logic is well lineralizable and data localized, and you can't implement access to some global hashmap in that way for example. Yes, because data can have thread affinity. Data doesn't need to be shared by _all _ connections, just by a few hundred/thousand. This enables connections to be scheduled to run on the same thread so that they can share data without synchronization. > I run this(10k threads blocked by DB access) in prod and it works fine for my needs. There are lots of statements in internet about overhead, but not much benchmarks how large this overhead is. The underlying problem is old and well researched: https://en.wikipedia.org/wiki/C10k_problem https://en.wikipedia.org/wiki/C10k_problem
        riku_iki 3y ago
        > Data doesn't need to be shared by _all _ connections, data doesn't need to be shared in your specific case, not in general. > The underlying problem is old and well researched: https://en.wikipedia.org/wiki/C10k_problem https://en.wikipedia.org/wiki/C10k_problem wiki page doesn't mean it is well researched, where can I see results of overhead measurements on modern hardware?
        3y ago

by jupp0r 3y ago

If you are using explicit blocking, share data between threads and have not run into deadlocks then your application is trivial (which is great if it solves your problem).

riku_iki 3y ago

Could you explain how sharing data between threads is different in async programming and blocking programming?

jupp0r 3y ago
You can minimize sharing data between threads because it's easier to have data affinity with threads (ie only thread A will read or write to a piece of data). You can still access that data from multiple modules because the whole thread is never blocked waiting for IO (because of async). An extreme example is nodejs, where you only have one thread, can concurrently do thousands of things and never have to coordinate (ie via mutexes) data access.
- riku_iki 3y ago
  that may be true if you are Ok to have only one thread and not utilize parallelism.
  - jupp0r 3y ago
    It's not either or, you can combine the two. I've worked on a system that did real time audio mixing for 10000s of concurrent connections, utilizing >50 cores, mostly with one thread each. Each thread had thread-local data, was receiving/sending audio packets to hundreds/thousands of different IP addresses just fine without worrying about mutexes at all. Try that with tens of thousands of actual OS threads and the associated scheduling overhead. Having data affinity to cores is also great for cache hit rates. Here is part of the C++ runtime this is based on: https://github.com/goto-opensource/asyncly https://github.com/goto-opensource/asyncly. I was the principal author of it when it was created (before it was open sourced).
    - riku_iki 3y ago
      > Each thread had thread-local data, was receiving/sending audio packets to hundreds/thousands of different IP addresses just fine without worrying about mutexes at all. it doesn't sound they really sharing data with each other, it looks like your logic is well lineralizable and data localized, and you can't implement access to some global hashmap in that way for example. > Try that with tens of thousands of actual OS threads and the associated scheduling overhead. I run this(10k threads blocked by DB access) in prod and it works fine for my needs. There are lots of statements in internet about overhead, but not much benchmarks how large this overhead is. > Here is part of the C++ runtime this is based on yeah, I need one runtime on top of another runtime, with unknown quality, support, longevity and number of gotchas.
      - jupp0r 3y ago
        > it doesn't sound they really sharing data with each other, it looks like your logic is well lineralizable and data localized, and you can't implement access to some global hashmap in that way for example. Yes, because data can have thread affinity. Data doesn't need to be shared by _all _ connections, just by a few hundred/thousand. This enables connections to be scheduled to run on the same thread so that they can share data without synchronization. > I run this(10k threads blocked by DB access) in prod and it works fine for my needs. There are lots of statements in internet about overhead, but not much benchmarks how large this overhead is. The underlying problem is old and well researched: https://en.wikipedia.org/wiki/C10k_problem https://en.wikipedia.org/wiki/C10k_problem
        riku_iki 3y ago
        > Data doesn't need to be shared by _all _ connections, data doesn't need to be shared in your specific case, not in general. > The underlying problem is old and well researched: https://en.wikipedia.org/wiki/C10k_problem https://en.wikipedia.org/wiki/C10k_problem wiki page doesn't mean it is well researched, where can I see results of overhead measurements on modern hardware?
        3y ago