Processes, threads and the freeze: unresponsiveness is a scheduling decision

An interface is judged in the half second after a person acts. When it fails that test, the failure is described as a drawing problem: the window stopped repainting, the button did not answer. This second of ten units argues for a scheduling description. The frozen window follows from running long work on the single thread that also draws and handles input, so responsiveness is bought by moving work off that thread.

The scarce resource is not arithmetic but one thread's attention. Heavy work moved to a background thread (Liu, Xu and Cheung, 2014). A platform's process management changed so one application stops competing with the rest (Sandhi, 2025). The four that follow leave the machine for the network.

Time-sharing manufactured responsiveness by reallocating the processor

Corbato, Merwin-Daggett and Daley (1962) describe the Compatible Time-Sharing System for the IBM 7090 and a scheduling algorithm built to give each of many users a machine that answers promptly. Responsiveness is manufactured by moving the processor from one job to another rather than by accelerating anything. A scheduler can switch the processor between threads, but it cannot make a thread finish its work.

The system on the MIT 7090 interleaved four users, three typing in the foreground and one running in the background. Every user program sat in the upper 27,000 words of core, with the supervisor in the lower 5,000. The scheduler gave each job a 16 millisecond quantum, sized at about 1 per cent switching overhead, and demoted a job a level when that quantum expired. On the machine of the day the authors estimated the system could serve four users with a worst-case response for a trivial reply of 32 seconds. They also estimated that a disc thirty times faster would carry 120 users at the same response.

One thread draws and handles input, and the platform decides whether it starves

The modern form of that structure is the single thread policy, which Liu, Xu and Cheung (2014) state for Android. The operating system creates a main thread, also called the UI thread. It dispatches system calls and user events, so lifecycle handlers and interface event handlers all run on that one thread. An application that overwhelms that thread with intensive work exhibits poor responsiveness.

From eight widely used Android applications Liu and colleagues (2014) collected 70 fixed performance bugs, of which 53 were interface lagging. The largest of three recurring causes was lengthy operations in main threads, at 11 of 52 attributable bugs. Their example is a thumbnail refresh whose click handler compressed bitmaps on the interface thread. The fix moved that work to a background thread.

Sandhi (2025) measured slow user-interface responsiveness across 47 million Android devices. The largest root cause is not slow code inside a handler. It is applications that consume resources disproportionately by exploiting the platform's optimistic process management, so the remedy belongs to the platform. A remodelled process manager using time-sensitive transitions is reported to cut slow responsiveness by 60 per cent and battery use by 10.7 per cent. The handset that freezes first is the one with the least to spare, and a blocked thread stops reporting the screen to the accessibility service.

Moving work off the thread has a price, and the price is shared state

Once work leaves the interface thread, two threads touch the same data. Lampson and Redell (1980) report monitors with condition variables in Mesa. They set out the difficulties the mechanism meets in a real system: nested monitor calls, the meanings of a wait, priority scheduling and timeouts. Synchronisation is difficult not because a primitive is missing. It is difficult because the structure of the shared state has to be decided.

Lu, Park, Seo and Zhou (2008) examined 105 real-world concurrency bugs from MySQL, Apache, Mozilla and OpenOffice. About 73 per cent of the non-deadlock bugs were not fixed by adding or changing locks. About 92 per cent could be triggered by ordering no more than four memory accesses.

The mechanism answers the problem but moves where the failure lands

The event position is that structure should be explicit. Welsh, Culler and Brewer (2001) build a service from event-driven stages joined by queues, with thread pools, batching and load shedding set by resource controllers. They report better behaviour under overload than a thread-per-request design. The thread position answers that the defect lies in implementations. von Behren, Condit and Brewer (2003) argue that threads can achieve what is claimed for events. They present a user-level thread package scaling to 100,000 threads, and they borrow a duality from Lauer and Needham that predicts good implementations of either style perform alike.

The answer depends on the stage of the work. Pai, Druschel and Zwaenepoel (1999) combine event-driven speed on cached requests with process speed on disk-bound work in one server. They report up to 50 per cent better than widely used servers. They measure several architectures in one implementation, so structure is the variable. Adya and colleagues (2002) separate task management from stack management. They open a third position in which code that reads like threaded code runs as events.

Hewitt, Bishop and Steiger (1973) propose actors as a single kind of object, each an active agent, in a formalism needing no goto, interrupt or semaphore primitives. Tu and colleagues (2019) test the promise in a language built on it. Across six widely used Go programs they analyse 171 concurrency bugs. More than half arose from mechanisms specific to Go, among them blocking on channels and closing them early.

Where the fix belongs: the language, the kernel or the platform rule

Boehm (2005) shows the fix cannot be the library alone. A threading library layered on a language whose compiler was designed without threading cannot guarantee correctness, since the compiler may reorder accesses the library assumes are ordered. Lee (2006) argues that threads as a general-purpose model hide the timing of interaction. He argues that they should be replaced by concurrency in which non-determinism is explicit and confined.

Anderson, Bershad, Lazowska and Levy (1992) mark the other boundary. Kernel thread performance is inherently worse than user-level performance, so they propose a kernel interface that calls into the user-level scheduler when processor allocation changes. On a phone the rule governing the interface thread is the platform's. The language gives guarantees a library cannot. The kernel boundary decides what a scheduler can promise, and the platform decides what an application may do at all.

Contested question: threads or events, and who owns the decision?

The first disagreement is which abstraction is sound. The event position, held by Welsh and colleagues (2001) and by Adya and colleagues (2002), is that explicit stages and queues give a system that stays well conditioned under load and can be reasoned about. The thread position, held by von Behren and colleagues (2003), is that the same properties come from a good thread implementation. It holds that supporting threads properly in the compiler is cheaper than rewriting a service as callbacks. Pai and colleagues (1999) came closest to a test, measuring several architectures in one server. Their metric is throughput under web load rather than felt latency, though, and no study here measures the freeze in a shipped interface under both structures.

The second axis is the owner of the decision. The owner may be the language (Boehm, 2005; Lee, 2006), the kernel boundary (Anderson et al., 1992) or the platform rule (Liu et al., 2014; Sandhi, 2025). What would settle it is a change of owner with all else held fixed. Sandhi's 60 per cent reduction is the closest published version and remains a deployment report. The two camps also measure in different currencies, throughput against bug incidence.

The two camps offer different kinds of evidence. The event position rests on a system measured under overload (Welsh et al., 2001) and on a design argument (Adya et al., 2002). The thread position rests on one user-level package tested for scale (von Behren et al., 2003). The owner question rests on a deployment report rather than a controlled trial (Sandhi, 2025). While the dispute is open, the designer chooses the abstraction the team can test and measures the freeze itself rather than a proxy. The strongest objection is that this unit's thesis, that unresponsiveness is a scheduling decision, rests on one platform study whose intervention bundled a process manager with everything else, so the scheduling change is not isolated.

Where the argument is heading

Lee (2006) asked for models in which non-determinism is contained by construction. Tu and colleagues (2019) show that changing the mechanism while keeping the model relocates the bugs. Anderson and colleagues (1992) show what the kernel would have to provide, and Sandhi (2025) is that idea at platform scale. Who holds the right to decide what occupies the thread that draws, and what measurement would show the decision wrong?

The sources this unit rests on

• Corbato, F. J., Merwin-Daggett, M. and Daley, R. C. (1962). An experimental time-sharing system. Spring Joint Computer Conference. doi:10.1145/1460833.1460871 Described the Compatible Time-Sharing System for the IBM 7090 and a scheduler interleaving many users on one processor so each saw a responsive machine. The origin of the claim that responsiveness comes from reallocating the processor.
• Hewitt, C., Bishop, P. and Steiger, R. (1973). A universal modular ACTOR formalism for artificial intelligence. International Joint Conference on Artificial Intelligence (IJCAI), 235 to 244. https://ijcai.org/proceedings/1973/0031.pdf Proposed actors as a single kind of object and a formalism that needs no goto, interrupt or semaphore primitives. It supplies the alternative to shared state, which an interface imports when work moves off the main thread.
• Lampson, B. W. and Redell, D. D. (1980). Experience with processes and monitors in Mesa. Communications of the ACM. doi:10.1145/358818.358824 Reported monitors with condition variables in a real system and documented the difficulties that follow: nested monitor calls, the meanings of a wait, priority scheduling and timeouts. It prices the fix this unit recommends, since the cost of moving work is protecting what the threads share.
• Anderson, T. E., Bershad, B. N., Lazowska, E. D. and Levy, H. M. (1992). Scheduler activations. ACM Transactions on Computer Systems. doi:10.1145/146941.146944 Argued that kernel thread performance is inherently worse than user-level performance and proposed a kernel interface upcalling the user-level scheduler when processor allocation changes. It places the decision at the kernel boundary, one of the three owners named here.
• Pai, V. S., Druschel, P. and Zwaenepoel, W. (1999). Flash: an efficient and portable web server. USENIX Annual Technical Conference. https://www.usenix.org/conference/1999-usenix-annual-technical-conference/flash-efficient-and-portable-web-server Combined event-driven behaviour on cached requests with multi-process behaviour on disk-bound work in one server and reported up to 50 per cent better than widely used servers. Its method, several structures in one implementation, comes closest here to the experiment the contested question asks for.
• Welsh, M., Culler, D. and Brewer, E. (2001). SEDA: an architecture for well-conditioned, scalable internet services. ACM Symposium on Operating Systems Principles (SOSP). doi:10.1145/502034.502057 Staged a service into event-driven stages joined by queues, with thread pools, batching and load shedding set by dynamic resource controllers, and reported better behaviour under overload than a thread-per-request design. The canonical statement of the event position.
• Adya, A., Howell, J., Theimer, M., Bolosky, W. J. and Douceur, J. R. (2002). Cooperative task management without manual stack management. USENIX Annual Technical Conference. https://www.usenix.org/conference/2002-usenix-annual-technical-conference/cooperative-task-management-without-manual-stack Separated task management from stack management, placed threaded and event-driven styles on independent axes, and identified a third position plus adaptors for mixing them in one code base. It shows the programmer need not choose between readable code and non-blocking behaviour.
• von Behren, R., Condit, J. and Brewer, E. (2003). Why events are a bad idea (for high-concurrency servers). Workshop on Hot Topics in Operating Systems (HotOS). https://www.usenix.org/conference/hotos-ix/why-events-are-bad-idea-high-concurrency-servers Argued that threads can match every claimed strength of events and presented a user-level thread package scaling to 100,000 threads with good server performance. The counter-position to SEDA and the strongest case that the freeze is a scheduler choice.
• Boehm, H. J. (2005). Threads cannot be implemented as a library. ACM SIGPLAN Notices. doi:10.1145/1064978.1065042 Showed that a threading library layered on a language whose compiler was designed without threading cannot guarantee correctness, since the compiler may reorder accesses the library assumes are ordered. It rules out the library as sole owner of the fix.
• Lee, E. A. (2006). The problem with threads. Computer. doi:10.1109/mc.2006.180 Argued that threads as a general-purpose abstraction hide the timing of interactions and should be replaced by models in which non-determinism is explicit and contained. It sets this unit's claim that the responsive interface is a concurrency design problem, not a drawing one.
• Lu, S., Park, S., Seo, E. and Zhou, Y. (2008). Learning from mistakes: a comprehensive study on real world concurrency bug characteristics. ACM SIGPLAN Notices. doi:10.1145/1353536.1346323 Examined 105 real-world concurrency bugs across MySQL, Apache, Mozilla and OpenOffice and found most non-deadlock bugs were not fixed by adding or changing locks. It sizes the cost of the move this unit recommends.
• Liu, Y., Xu, C. and Cheung, S. C. (2014). Characterizing and detecting performance bugs for smartphone applications. International Conference on Software Engineering (ICSE). doi:10.1145/2568225.2568229 Stated Android's single thread policy, then studied 70 fixed performance bugs in eight widely used applications, of which 53 were interface lagging, and identified lengthy operations in main threads as the largest recurring cause. Their example, repaired by moving bitmap work off the interface thread, is the thesis as a patch.
• Tu, T., Liu, X., Song, L. and Zhang, Y. (2019). Understanding real-world concurrency bugs in Go. ACM International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS). doi:10.1145/3297858.3304069 Analysed 171 concurrency bugs in six widely used Go programs, including Docker, Kubernetes and gRPC, and found more than half caused by mechanisms specific to Go. It tests the actors-versus-shared-state argument and shows the mechanism trades one failure mode for another.
• Sandhi, K. (2025). Mitigating slow UI responsiveness in modern mobile systems: a large-scale study and optimized Android process management. International Conference on Networks and Soft Computing (ICNSoC). doi:10.1109/icnsoc66817.2025.00143 Measured slow responsiveness across 47 million Android devices, identified applications that hog resources by exploiting the platform's optimistic process management as the largest root cause, and reported a remodelled process manager cutting slow responsiveness by 60 per cent. The current measured version of the freeze, and the evidence that the largest fix came from the platform.