0

I have understood that one major advantage of asynchronous functions is that fewer threads reduces context switches. However, when I compare context switches between synchronous and asynchronous programming, I find that fewer threads only eliminates context switches from thread scheduling.

Below I lay out when I think context switches occur. I have not verified that these steps are correct.

Context switches with synchronous calls

  1. User thread runs.
  2. User thread reaches write function call.
  3. User thread traps into kernel mode. (context switch)
  4. OS performs write.
  5. OS returns control to some other thread. Back to step 1. (context switch)

Context switches with asynchronous calls

Assume there is only one user thread running.

  1. Single user thread runs.
  2. User thread reaches async_write function call.
  3. User thread traps into kernel mode. (context switch)
  4. OS schedules write.
  5. OS returns control to user thread. Back to step 1. (context switch)

The Question

In either of the above examples, there are two context switches. Asynchronous programming is not reducing the number of context switches. What am I missing?

mbang
  • 855
  • 2
  • 9
  • 1
    You might be asking the wrong question. If I'm remembering my boost correctly this stuff is based on top of `epoll`, `select`, or Overlapped IO depending on what the underlying system offers or uses most effectively. Whatever's going on beneath `epoll`, or whatever is someone else's problem, but no small amount of the savings is the overall reduction in the number of threads needed. The IO is likely serialized in one thread and the handling of responses done by a pool. – user4581301 Sep 21 '22 at 22:23
  • Rather than hopping around one thread per connection (tonnes of context switches) or other easy-to-code, hard-to-scale solutions, relatively few threads just go from one job to the next and bother the kernel and each other as little as possible. – user4581301 Sep 21 '22 at 22:23
  • "overall reduction in the number of threads needed" My understanding is that one reason reducing the number of threads is useful is because it reduces context switches, hence the OP. – mbang Sep 21 '22 at 22:35
  • "this stuff is based on top of ```epoll```, ```select```" I think you are talking about how **after** the I/O is scheduled, these are called by [```io_context::run()```](https://www.boost.org/doc/libs/1_80_0/doc/html/boost_asio/reference/io_context.html) to verify that the operation is complete. I am talking about when the send is initiated. – mbang Sep 21 '22 at 22:40
  • Wouldn't be the first time I've read a question wrong. – user4581301 Sep 21 '22 at 22:53
  • With boost asio you can create a program which does not block while doing networking and is single threaded. This allows you to add threads only for performance reason and not for communication reasons. – Koronis Neilos Sep 23 '22 at 12:49

0 Answers0