# IO vs CPU operations

DevFeed: [IO vs CPU operations](<https://devfeed.tech/articles/io-vs-cpu-operations-25268.md>)

Original publisher: [Read original article](<https://kau.sh/blog/io-cpu-bound-threads/>)

Author: Kaushik Gopal

Published: 2019-06-03T07:00:00Z

Content type: tutorial

Language: en

Sources: [Kaushik Gopal's Site](<https://devfeed.tech/sources/kaushik-gopal-s-site.md>)

Topics: [Programming](<https://devfeed.tech/topics/programming.md>), [Concurrent Programming](<https://devfeed.tech/topics/concurrent-programming.md>), [IO](<https://devfeed.tech/topics/io.md>), [cpu](<https://devfeed.tech/topics/cpu.md>), [Operating system](<https://devfeed.tech/topics/operating-system.md>), [Mobile](<https://devfeed.tech/topics/mobile.md>)

Tags: [background-work](<https://devfeed.tech/tags/background-work.md>), [cpu](<https://devfeed.tech/tags/cpu.md>), [io](<https://devfeed.tech/tags/io.md>), [mobile](<https://devfeed.tech/tags/mobile.md>), [os](<https://devfeed.tech/tags/os.md>), [programming](<https://devfeed.tech/tags/programming.md>), [thread](<https://devfeed.tech/tags/thread.md>)

## AI overview

The article explains why I/O-bound and CPU-bound work should use different thread pools. I/O operations wait on hardware and can leave threads sleeping, while CPU work performs computation; mixing them can delay CPU work behind I/O waits.

## Source excerpt

This is a fantastic post by Erik where he explains the nuance between IO-bound and CPU-bound operations in programming. ... libraries have dedicated APIs for I/O scheduling work, separate from other types of operations .... but why is this the case? Why don't we use a single thread pool for all background operations? The operating system will handle the scheduling of these threads the same I love how this specific question is framed (a good interview question for advanced mobile developers): Why can't we just split work into: main (or UI) thread and "all other background work" thread pool? This way the UI shouldn't stutter and if you have a pool of threads running in the background, all that background work will conveniently be executed, no problem. Right? Even though both I/O-bound and CPU-bound work need to be executed in the background for mobile development, they have different demands and stress the operating system (OS) differently. Hence the need for different thread pool types to handle this kind of work differently. CPU operations (like number crunching, computation etc.) run incredibly fast I/O operations on the other hand (reading from a database, network etc.) take longer as the OS has to wait for underlying hardware to retrieve and deliver the data Typically the underlying hardware sends out a signal IOWait to the OS while the underlying hardware is out and about doing the IO work Instead of sitting and twiddling its thumbs, the OS should be finishing other tasks in the meantime (especially ones that are not waiting on underlying hardware) through other threads When the operating system encounters an IOwait, it pauses the execution of that thread and is free to pick up another thread that is ready to run. Theoretically, an operating system can have an unlimited number of threads that are sleeping due to IOwait, without the user noticing any difference That last point is subtle: this is why you don't want to mix CPU and I/O threads in the same pool. You coul