Why user threads are mapped to Kernel threads

The term "kernel threads" can be used to refer to actual threads that run entirely in kernel space or it can refer to user-space threads scheduled by the kernel. The term "kernel-supported" threads means the latter, threads that run in user-space but are facilitated by the kernel, which usually means the kernel schedules them.

"User-level threads" usually means threads visible to user space. That is, what you create when you call your threading standard's "create thread" function. Generally, the term "user-level thread" is used to mean a thread created by the application code regardless of how it's implemented by the system. It may be a pure user-space thread with little to no kernel support or it may be a thread scheduled by the kernel.

The pthreads standard can be implemented as pure user-space threads (where the kernel schedules the process and the process schedules the threads), kernel-supported threads (where the kernel schedules the threads directly), or a hybrid approach (where the kernel schedules a kernel-level thread which then, in user-space, schedules a user-level thread). The standard doesn't demand any one particular means of implementation. The most common implementation is 1-to-1 mapping where each user-level thread has a corresponding thread that is scheduled by the kernel.

I remember the JVM abandoning green threads and moving to native threads. This was for two simple reasons: the green threads were frankly rubbish, and there was a need to support multi-core processors with the limited developer effort available at Sun.

This was a shame - green threads provide a far better abstraction, allowing concurrency to be a useful tool not a stumbling block. But green threads are no use if several hurdles can't be overcome:

• they must use all the cpu cores available to them

• context switching must be cheap

• I/O may block any thread engaged in it, but not any other thread and certainly not all other threads, which was the case in some early implementations.

I've often wondered why multi-threading is so hard in Java but it's now becoming clearer - it was ultimately to do with the switch to native threads, which are:

• good at using all the cpu cores

• good at being truly concurrent, providing independent I/O etc

• slow at context switching (compared with the best green thread implementations)

• horribly greedy with memory, hence limiting the maximum usable number of them

• a poor abstraction for any basis for expressing the real world, which is highly concurrent of course.

Nowadays, a lot of programmer time now goes into coding up non-blocking I/O, futures etc. It's a big shame we don't have a better level of abstraction.

For comparison, besides Erlang the new Go language does a good job of huge concurrency. The grand-daddy of them all remains Occam, still an ongoing research project.