Threads de usuários em um processo único. A troca de threads é gerenciada com alarmes e a bilioteca thread gerencia todas as funções não segura as threads com travamento. Operações de leitura, excrita e operação são normalmente gerênciada com uma select específica da thread que troca para outra thread se a thread em execução tiver que esperar por dados. Se os pacotes de threads do usuário estão integrados com as bibliotecas padrão (threads FreeBSD e BSDI) o pacote da thread exige menos sobreposicao que pacotes de threads que têm que mapear todas as chamadas não seguras (MIT-pthreads, FSU Pthreads e RTS threads). Em alguns ambientes (SCO, por exemplo), todas as chamadas do sistema são seguras a threads e assim o mapeamento pode ser feito muito facilmente (FSU Pthreads em SCO). Desvantagem: Todas as chamadas mapeadas levam pouco tempo e é bem malicioso para tratar todas as situações. Também há, normalmente, algumas chamadas de sistema que não são tratados pelo pacote de thread (como MIT-threads e sockets). O agendamento de threads nem sempre é ótimo.

Threads de usuários em processos separados. A troca de threads é feita pelo kernel e todos os dados são compartilhados entre threads. O pacote de thread gerência as chamadas padrão de threads para permitir o compartilhamento de dadps entre threads. LinuxThreads é usado neste método. Desvantagem: Diversos processos. A criação de thrads é lenta. Se uma thread morrer as outras normalmente travarão e você você deverá matá-las antes de reiniciar. A troca de threads também tem um custo um pouco alto.

Threads de kernel. A troca de threads é feita pela biblioteca de thread ou pelo kernele é muito rápida. Tudo é feito em um processo, mas em alguns sistema, ps pode mostrar threads diferentes. Se uma thread abortar, todo o processo é abortado. A maioria das chamadas do sistema são seguras a threads e devem exigir muito pouca sobrecarga. Solaris, HP-UX, AIX e OSF/1 têm threads de kernel.