what are the difficulties of operating system multithreading?

Question

I am reading a book that compares two ways of implementing threads, Middleware Threads and OS Threads. I don't know what the meaning of these sentences are exactly: "A difficulty of operating system multithreading, however, is performance overhead. Since it is the operating system that is involved in switching threads, this involves system calls. These are generally more expensive than thread operations executed at the user level, which is where the transactional middleware is operating." and What is the relation of system calls and performance?

Answer 1

For most modern operating systems. (Windows, *nix, MAC OS), the operating system kernel resides in a protected address space. And in order to maintain the integrity of that protected space, that space can only be entered from user space at known locations. So it is somewhat more expensive to make a call into the operating system than it is to make an ordinary function call in user space. http://en.wikipedia.org/wiki/System_call.

The 286 CPU was fairly slow at getting from user space to kernel space, but more recent CPU architectures, like current x86 and IA64 have special instructions specifically designed to make the transition from user space to kernel space as fast as possible, and while it is still more expensive than a normal function call in user space, I don't think justifies the level of concern that this book indicates.

Answer 2

As the text you quoted says, system calls are generally more expensive than a user-level thread operation.

Some things that can make a system call expensive (compared to a user-level function call):

• saving/restoring processor state
• updating the virtual memory environment for access to kernel space
• when the system call completes, there may be a trip through the OS scheduler

Answer 3

The book is probably a bit dated, middleware threads (aka fibers) were popular about 10 years ago. Yes, context switches are relatively expensive, somewhere between 2000 and 10,000 CPU instructions. They require a kernel transition and acquiring a global lock. User threading can avoid a large portion of that cost, only the CPU state needs to be switched.

But that doesn't come for free:

• You'll need to create your own scheduler
• When a user thread blocks on an I/O operation, all user threads will block
• A user context switch blows the CPU cache.

The latter issue is the big one, blowing the cache is really expensive. CPU cores have become so fast compared to memory that the cost of trashing the cache becomes comparable to an OS context switch. And getting a lot of CPU cores is cheap.