A empresa Google um conjunto inicial de patches para inclusão no núcleo Linux com a implementação de componentes necessários para suportar o funcionamento do modelo de threads M:N. A iniciativa do Google está relacionada à abertura de uma API que estava em desenvolvimento a portas fechadas para o núcleo Linux, que suporta a implementação de um subsistema de múltiplas threads em espaço de usuário, usando o modelo de threads M:N. O subsistema é utilizado pelo Google para garantir o funcionamento de serviços que requerem latências mínimas. O agendamento e o gerenciamento da distribuição de threads são feitos inteiramente no espaço de usuário, o que permite reduzir significativamente o número de operações de troca de contexto ao minimizar as chamadas de sistema.
Para garantir o funcionamento do subsistema mencionado no nível do núcleo Linux, foi implementada a API SwitchTo, que oferece três operações básicas — wait, resume e swap (troca). Foi proposto um código para uma nova operação FUTEX_SWAP, que complementa , e fornece uma base para a criação de bibliotecas de múltiplas threads em espaço de usuário. O FUTEX_SWAP também pode ser utilizado para a troca de mensagens entre tarefas, de forma semelhante ao RPC. Por exemplo, atualmente, para enviar uma mensagem entre tarefas, é necessário realizar pelo menos quatro chamadas FUTEX_WAIT e FUTEX_WAKE, enquanto o uso do FUTEX_SWAP permitirá uma operação única que será executada de 5 a 10 vezes mais rápido.
Atualmente, na prática, são utilizadas principalmente os modelos de threads 1:1 e N:1. O modelo 1:1 é usado em (threads POSIX) e , e implica uma correspondência direta de uma thread no espaço de usuário com uma thread (unidade de agendamento) no nível do núcleo. O modelo N:1 é implementado em , deslocando a gestão de threads para o espaço de usuário e permitindo que N threads em espaço de usuário fiquem ligadas a uma única thread no núcleo, sendo que o núcleo não tem informação sobre as threads de usuário.
A principal desvantagem do modelo 1:1 é o grande overhead causado pela troca de contexto entre o núcleo e o espaço do usuário. O modelo N:1 resolve esse problema, mas cria um novo — já que o fluxo no núcleo é uma unidade discreta de planejamento de execução, os fluxos de usuário vinculados a um único fluxo no núcleo do sistema operacional não podem ser escalonados entre os núcleos da CPU e acabam atados a um único núcleo da CPU.
O modelo M:N é híbrido e elimina todas as desvantagens descritas acima ao mapear N fluxos no espaço do usuário para M fluxos no núcleo do sistema operacional, o que permite reduzir o overhead da troca de contexto e garantir a escalabilidade entre os núcleos da CPU. O preço dessa opção é a complexidade adicional na implementação do planejador de fluxos no espaço do usuário e a necessidade de mecanismos de sincronização das ações com o planejador do núcleo.
Fonte: opennet.ru
