Como os threads são implementados em diferentes sistemas operacionais?

Eu estava lendo Linux Kernel Development de Robert Love, onde me deparei com isso

O Linux adota uma abordagem interessante ao suporte a threads: não diferencia entre threads e processos normais. Para o kernel, todos os processos são iguais - alguns simplesmente compartilham recursos.

Eu não sei muito sobre sistemas operacionais (aspira a saber mais) e kernels e, portanto, a citação acima levantou uma questão sobre implementações de threads em diferentes sistemas operacionais (pelo menos os populares como Windows, Linux e Unix).

Alguém pode explicar as diferentes técnicas para fornecer suporte a threads em um sistema operacional? (e opcionalmente contrastá-los)

operating-systems process-scheduling threads

— Ankit
fonte

Você pode dar uma olhada na resposta a esta pergunta no stackoverflow .

— Pedro

Esta pergunta parece ser sobre o Linux especificamente. Como tal, é offtopic aqui e deve estar no Unix e Linux . Se é para ser uma pergunta geral do sistema operacional, edite para esclarecer isso.

— Raphael

@ Pedro Obrigado, mas não é o que eu estava confuso. Essa pergunta (o que eu sinto) é mais sobre questões de desempenho e bloqueio, e assim por diante. Estou interessado em possibilidades como são tópicos realmente implementadas e diferentes

— Ankit

@ Rafael Obrigado. Eu o colocaria naquele lugar (apenas se soubesse disso). Então, meu mal, eu não procurei pela comunidade Linux no stackexchange. Você pode migrar?

— Ankit

@ Rafael, a questão é entender as consequências de várias abordagens para uma questão de sistemas operacionais, como eu a entendo. (btw, eu não acho que ser específica do Linux faz um tema fora de questão aqui.)

— Kaveh

Threads e processos são contextos de execução. Eles diferem principalmente apenas pela quantidade de estado compartilhado (memória, manipuladores de sinal, descritores de arquivo, ...) com os outros contextos de execução (processos compartilham pouco com outros processos; threads compartilham muito com os outros threads no mesmo processo).

A maioria dos sistemas operacionais mantém as duas coisas separadas e, portanto, conhece vários tipos de contexto de execução.

O kernel do Linux, por outro lado, possui apenas um tipo de contexto de execução, capaz de compartilhar ou não as coisas com os outros. Se você deseja um processo, configure-o para que ele compartilhe pouco, ou para threads, configure-os para que eles compartilhem o que precisam. Você pode configurar as coisas para que elas se comportem de maneira inadequada para a terminologia do processo / encadeamento.

A API POSIX normalmente usada quando a programação para Linux conhece apenas processos e threads e, portanto, a maioria dos programas realmente não se importa com o que é um detalhe de implementação para eles na maneira como as responsabilidades são divididas entre o kernel e o espaço do usuário. Implementações mais antigas de threads vazaram alguns detalhes da implementação (ps mostrando threads, identificação de thread e identificação de processo se misturando, ...) e não forneceram a semântica exata do POSIX em alguns casos (a entrega do sinal era problemática IIRC).

— AProgrammer
fonte

Acho que você está perdendo parte da complexidade do agendador do Linux. Ele sabe se os threads pertencem ao mesmo processo. Também existem threads de userland. Além disso, isso parece ser mais uma resposta do SO, sobre a implementação concreta, do que uma resposta do CS, explicando os conceitos.

— Gilles 'SO- stop be evil'