3

What are user threads? Below explanation says they are managed by userspace... Please explain how?

Threads are sometimes implemented in userspace libraries, thus called user threads. The kernel is not aware of them, so they are managed and scheduled in userspace.

skaffman
  • 398,947
  • 96
  • 818
  • 769
Raghu D P
  • 31
  • 1
  • It seems this is more of a question for http://www.superuser.com, since there's no direct link to programming anywhere in the question. – AVH Apr 21 '11 at 13:48
  • 1
    Users don't deal in libraries, threads, or kernels; sounds like an architecture question to me! – Ernest Friedman-Hill Apr 21 '11 at 13:50

3 Answers3

4

Every modern server or desktop OS, and all major mobile OSs, have a native thread library these days, so this question is not very relevant anymore. But basically, before this was the case, there were libraries -- most famously, the "Green threads library" -- which implemented cooperatively-multitasking threads as a user library. That "cooperatively multitasking" part is the important part: in general, such a library switches from one thread to another only when the thread calls some method that allows a switch to happen ("sleep", "yield", etc.) A user library generally can't do preemptive time-slicing; that's something that has to be done at the OS level.

Ernest Friedman-Hill
  • 80,601
  • 10
  • 150
  • 186
  • 1
    "A user library generally can't do preemptive time-slicing" - Although a bytecode interpreter can yield after a certain number of instructions, or a JIT can insert yield calls into its emitted code, to give the impression of pre-emption and prevent compute-intensive threads hogging the CPU. – Steve Jessop Apr 21 '11 at 14:01
  • Indeed -- but then each bytecode is effectively one of those possibly-yielding function calls. – Ernest Friedman-Hill Apr 21 '11 at 14:03
  • 1
    Yep, the code doesn't have the option to *not* co-operatively multitask. I just mention it because it means green threads can work much better than horror stories people might have heard about co-operative multitasking. At least up to the point where native libraries used by the VM take a long time to do something. – Steve Jessop Apr 21 '11 at 14:04
  • It's completely possible, with signal handlers and `ucontext`, to do preemptive context switching entirely in userspace. – R.. GitHub STOP HELPING ICE Apr 25 '11 at 13:35
  • @R: Now we're splitting hairs. Signals (i.e., interrupts) can be used, sure: but those are OS-level functions, and the APIs are just putting knobs on those OS functions so that user programs can touch them. Not all OSs have them, nor are the APIs/semantics portable. – Ernest Friedman-Hill Apr 25 '11 at 13:57
0

Symbian OS has an Active Object framework that allows async event handling in a single thread http://en.wikipedia.org/wiki/Active_object_%28Symbian_OS%29

Windows also has Fibres: http://msdn.microsoft.com/en-us/library/ms682661%28v=vs.85%29.aspx

James
  • 9,064
  • 3
  • 31
  • 49
0

Kernel threads (also called lightweight process) are handeled by the system. They offer several interesting benefits, the main one being that two threads can be scheduled on two different processors in the hope that this will reduce the execution time of your process.

However threads are often used as a programming model. A typical example is a multi-client webserver that waits for incoming connexion and simultaneously exchange data with its connected clients. In this case the programmer may want to create a lot of threads and switch between them very quickly. System threads are not very adapted to this. The number of kernel threads is limited (to few undreads) and any basic operation (creation destruction switching locking) is costly since it must be executed in kernel space.

The user threads on the other hand, can be implemented using set_jmp() and long_jmp() inside a user library. Since they don't involve the kernel an application can create/destroy and switch between user threads very efficiently.

As Ernest said, user threads are not very common any more, however there exists a hybrid solution that can take advantages of the two worlds.

http://en.wikipedia.org/wiki/Thread_(computer_science)#N:M_.28Hybrid_threading.29

Ben
  • 7,372
  • 8
  • 38
  • 46
  • 1
    User threads cannot be implemented with SJLJ alone, because they only work on a single stack. You at least need some machine-specific code (or ugly `sigaltstack`-based hacks) to setup new stacks. – R.. GitHub STOP HELPING ICE Apr 25 '11 at 13:37