Há sistemas nos quais threads podem ser suportados no nível ...

Gabarito: Errado

Vamos entender o porquê essa alternativa está incorreta.

Em um sistema operacional, as threads podem ser gerenciadas em dois níveis: nível de usuário e nível de kernel (sistema operacional). Vamos analisar ambos:

Threads no nível de usuário: São gerenciadas pela própria aplicação ou bibliotecas de tempo de execução, sem envolvimento direto do kernel. Esse gerenciamento pode ser mais leve e eficiente, mas tem suas limitações, especialmente na utilização de múltiplos processadores.

Threads no nível de kernel: Gerenciadas pelo próprio sistema operacional. Permitem uma melhor utilização dos recursos do sistema, como múltiplos núcleos de processadores, trazendo uma maior concorrência real.

Agora, vamos à questão da multiplicidade de mapeamento:

Quando se diz que mais de um thread no nível de usuário é mapeado para um thread no nível de sistema operacional, estamos falando de um modelo conhecido como M:N (M threads de usuário para N threads de kernel). Embora esse modelo busque um equilíbrio entre flexibilidade e desempenho, ele não garante maior concorrência. Na verdade, pode levar a um problema onde, mesmo que múltiplas threads de usuário estejam prontas para serem executadas, elas ficam limitadas à quantidade de threads de kernel disponíveis.

Para garantir melhor concorrência, o ideal é usar um modelo onde exista uma correspondência mais direta entre threads de usuário e threads de kernel, como no modelo 1:1 (uma thread de usuário para uma thread de kernel). Assim, cada thread de usuário pode realmente utilizar os recursos do sistema operacional para execução concorrente.

Portanto, a afirmativa de que mapear mais de um thread no nível de usuário para cada thread no nível de sistema operacional aumentaria a concorrência está incorreta. Esse modelo pode, na verdade, limitar a concorrência ao invés de aumentá-la.

Se houver qualquer dúvida sobre threads ou outras questões, sinta-se à vontade para perguntar!

As threads do sistema são gerenciadas no Modo Kernel, que entre outras coisas realiza a Troca de Contexto Preemptiva, e as threads do usuário são gerenciadas no Modo Usuário, em que as Trocas de Contexto são Cooperativas

A questão trata de modelos de multithreads. Tem-se que há 3 modelos de multithread:

Muitos para um:  vários threads de usuário são mapeados em um único thread de kernel. Se um thread fizer uma chamada bloqueante o processo inteiro será bloqueado. Com isso a concorrência fica prejudicada.

Um para um: cada thread de usuário é mapeado em um thread de kernel. Há uma maior concorrência que no modelo muitos para um,mas pode provocar queda de desempenho do sistema. 

Muitos para muitos: threads de usuários são multiplexados em um número menor de threads de kernel.

O erro da questão está em dizer que com o modelo muitos para um (mais de um para cada um) obtém maior concorrência.

Fonte: http://www.oocities.com/whisatugu/threads.pdf
 

resumindo as respostas dos colegas:

multithreading:

Modelo Muitos-Para-Um- varios threads nível de usuário para 1 thread do kernel. O gerenciamento no espaço do usuário; processo inteiro bloqueado. somente um thread pode acessar o kernel de cada vez, múltiplos threads não executam em paralelo em multiprocessadores.

Modelo Um-Para-Um - 1 thread de usuário para um thread kernel: maior concorrência do que o modelo muitos-para-um. enquanto um thread realiza uma chamada de sistema de bloqueio, ele também permite que múltiplos threads executem em paralelo em multiprocessadores. desvantagem: criação de um thread de usuário exige a criação do correspondente thread de kernel.

Modelo Muitos-Para-Muitos- muitos threads de nível de usuário para um número menor ou igual de threads de kernel. O número de threads de kernel pode ser específico tanto para uma aplicação quanto para uma máquina em particular. ha execucao paralela em multiprocessador. quando um thread realiza uma chamada de sistema de bloqueio, o kernel pode agendar um outro thread para execução.