Threads No Modo núcleo

O uso de um tipo de processo dentro de um processo, também conhecido como mini-processos ou threads, pode ser questionável. A justificativa é que em várias aplicações ocorrem muitas atividades simultaneamente, que podem ser bloqueadas em alguns momentos. Além disso, criar ou destruir um thread é mais rápido que fazer isto com processos, que podem ter vários recursos associados. Quando ocorre uma grande quantidade de computação e E/S, os threads permitem a sobreposição destas atividades, acelerando a aplicação.

Há dois métodos de implementar um pacote de threads: no espaço do usuário e no núcleo. O primeiro consiste em inserir o pacote de threads dentro do espaço do usuário (threads de usuário), logo o núcleo não é informado sobre eles e apenas executa o gerenciamento comum de processos monothread.

Já no modo núcleo, o núcleo sabe dos threads e os gerencia através de uma tabela de threads que acompanha todos os threads no sistema. Diante da necessidade de criar um novo thread ou destruir um existente, é feita uma chamada ao núcleo que realiza o processo solicitado atualizando, então, a tabela de threads.

Esta tabela contém estados, registradores e outras informações acerca de cada thread. Essas informações constituem um subconjunto das informações que os núcleos tradicionais mantêm sobre cada um de seus processos monothreads, isto é, o estado do processo. Além disso, o núcleo também mantem a tradicional tabela de processos para o acompanhamento destes.

Todas as chamadas que possam bloquear um thread são implementadas como chamadas de sistema. Quando um thread é bloqueado, é opção do núcleo executar outro thread do mesmo processo ou de outro processo. O sistema de tempo de execução mantém os threads de seu próprio processo executando até que o núcleo retire a CPU dele ou até que não haja mais threads prontos para executar.

A reciclagem de threads é uma prática adquirida por alguns sistemas devido ao custo relativamente maior de criar e destruir threads de núcleo. Durante a exclusão de um thread, este é marcado como não executável, porém suas estruturas de dados não sofrem alterações. Se for preciso criar um novo thread, um thread antigo é reativo, economizando alguma sobrecarga.

Os threads de núcleo, além disso, não precisam de nenhuma chamada de sistema bloqueante. Se um thread em processo causa uma falta de página, o núcleo pode facilmente verificar se o processo tem threads para execução e, em caso afirmativo, pode executá-los enquanto aguarda a página requisitada ser trazida do disco. A principal desvantagem é que o custo de uma “system call” é alto e, portanto, a ocorrência frequente de operações de um thread causará uma sobrecarga muito maior.

Ainda que os threads de núcleo resolvam alguns problemas, não resolvem todos. Diante da bifurcação de um processo multithread há duas situações que dependem do que o processo fará em seguida. Caso chame exec para executar um novo programa, provavelmente apenas um thread será mantido. Se continuar a executar, a replicação de todos os threads é necessária.

Outra questão são os sinais, enviados para processos e não para os threads. Os threads podem registrar seus interesses em certos sinais, assim quando este chegasse seria direcionado ao thread que o requisitasse. E se dois registrarem interesse ao mesmo sinal? Estes