User level threads that are not managed by the kernel. They are managed by programs in user mode.
https://docs.oracle.com/cd/E19455-01/806-5257/mtintro-54820/index.html
They are generally seen as a single unit to the Operating System. If a necessity comes for a single thread to process I/O, the entire process which is handling/scheduling threads is blocked i.e., they are transparent to OS. OS doesn't know the existence of these threads.
Why do we still use it?
- They are fast to launch and switch. No kernel mode bit switch which is expensive.
- Their scheduling can be managed in order by user programs rather than OS.
- Can be implemented on OS which do not support threading. (OS doesn't know that threads are running at all).
How are they scheduled?
A program <user level scheduler> which takes control of the CPU shares it's space (memory) with the threads. It then puts the code of a thread onto the CPU.
The context switching could happen in two ways
- Either the current thread deliberately vanquishes control of CPU by calling sleep() {voluntarily}
- Scheduler schedules in a way such that after certain amount of time it gets the control back.