Skip to content

Cooperative User Threads vs. Preemptive Kernel Threads

James Robertson, Cooperative Threading:

Well, in Cincom Smalltalk, this model gives you predictability – you know exactly what a thread is going to do. The issue with runaway threads rarely comes up for a simple reason – most processes end up pausing for I/O (user input, db access, file access, sockets – what have you). That wait for I/O state is what prevents a problem from arising.

This is a classic problem and I’m honestly surprised to find out that Cincom Smalltalk implements cooperative user-level threads rather than supporting preemptive kernel threads.

Here’s what I posted in response to James, unattributed thanks to the torturous comment interface on his blog:

One issue with cooperative threads relative to preemptive OS-supplied threads is that you get far less opportunity for true concurrency within an application. In an era when multi-core processors are becoming significantly more common, this is becoming exceptionally important to application developers. It’s not just about doing I/O concurrently with other operations or allowing an application to perform multiple tasks at once; it’s about allowing a task to be completed faster because more efficient use is being made of machine resources. This is why I take an extremely skeptical view of user-level threading packages, especially in software built on platforms that have reasonable kernel-level threading.

You’ll note that the various threading APIs in Mac OS X are all built on kernel threads.

Furthermore, the Mach microkernel schedules exclusively in terms of threads. The microkernel doesn’t even have a conception of processes! It only knows about collections of resources — tasks — such as address spaces and IPC ports, and flows of control — threads — that it can schedule on processors.

Post a Comment

Your email is never published nor shared. Required fields are marked *