The translation is temporarily closed for contributions due to maintenance, please come back later.
English Portuguese (Brazil)
$FreeBSD$
There are currently two ways to implement threading in FreeBSD. The first way is M:N threading followed by the 1:1 threading model. The default library used is M:N threading (<literal>libpthread</literal>) and you can switch at runtime to 1:1 threading (<literal>libthr</literal>). The plan is to switch to 1:1 library by default soon. Although those two libraries use the same kernel primitives, they are accessed through different API(es). The M:N library uses the <literal>kse_*</literal> family of syscalls while the 1:1 library uses the <literal>thr_*</literal> family of syscalls. Due to this, there is no general concept of thread ID shared between kernel and userspace. Of course, both threading libraries implement the pthread thread ID API. Every kernel thread (as described by <literal>struct thread</literal>) has td tid identifier but this is not directly accessible from userland and solely serves the kernel's needs. It is also used for 1:1 threading library as pthread's thread ID but handling of this is internal to the library and cannot be relied on. Atualmente existem duas maneiras de implementar o threading no FreeBSD. A primeira maneira é o threading M:N seguido pelo modelo de threading 1:1. A biblioteca padrão usada é o threading M:N (<literal>libpthread</literal>) e você pode alternar no tempo de execução para threading 1:1 (<literal>libthr</literal>). O plano é mudar para a biblioteca 1:1 por padrão em breve. Embora essas duas bibliotecas usem as mesmas primitivas do kernel, elas são acessadas por API(s) diferentes. A biblioteca M:N usa a família <literal>kse_*</literal> das syscalls enquanto a biblioteca 1:1 usa a família <literal>thr_*</literal> das syscalls. Por causa disso, não existe um conceito geral de ID de threading compartilhado entre o kernel e o espaço do usuário. Obviamente, as duas bibliotecas de threads implementam a API de ID de threading pthread. Todo threading do kernel (como descrito por <literal>struct thread</literal>) possui identificadores td tid, mas isso não é diretamente acessível a partir do espaço do usuário e serve apenas as necessidades do kernel. Ele também é usado para a biblioteca de threading 1:1 como o ID de threading do pthread, mas a manipulação desta é interna à biblioteca e não pode ser confiável.
As there is a difference in view as what to the idea of a process ID and thread ID is between FreeBSD and <trademark class="registered">Linux</trademark> we have to translate the view somehow. We do it by PID mangling. This means that we fake what a PID (=TGID) and TID (=PID) is between kernel and userland. The rule of thumb is that in kernel (in Linuxulator) PID = PID and TGID = shared -&gt; group pid and to userland we present <literal>PID = shared -&gt; group_pid</literal> and <literal>TID = proc -&gt; p_pid</literal>. The PID member of <literal>linux_emuldata structure</literal> is a FreeBSD PID. Por causa da visão diferente descrita sabendo o que é um ID de processo e ID de thread entre o FreeBSD e o <trademark class="registered">Linux</trademark> nós temos que traduzir a view de alguma forma. Nós fazemos isso pelo manuseio do PID. Isto significa que nós falsificamos o que um PID (=TGID) e um TID (=PID) é entre o kernel e o userland. A regra é que no kernel (no Linuxulator) PID=PID e TGID=grupo de id -&gt; compartilhado e para userland nós apresentamos <literal>PID=shared -&gt; group_pid </literal> e <literal>TID=proc -&gt; p_pid</literal>. O membro PID da estrutura <literal>linux_emuldata </literal> é um PID do FreeBSD.
The locking is implemented to be per-subsystem because we do not expect a lot of contention on these. There are two locks: <literal>emul_lock</literal> used to protect manipulating of <literal>linux_emuldata</literal> and <literal>emul_shared_lock</literal> used to manipulate <literal>linux_emuldata_shared</literal>. The <literal>emul_lock</literal> is a nonsleepable blocking mutex while <literal>emul_shared_lock</literal> is a sleepable blocking <literal>sx_lock</literal>. Due to the per-subsystem locking we can coalesce some locks and that is why the em find offers the non-locking access. O bloqueio é implementado como per-subsystem porque não esperamos muita disputa sobre eles. Existem dois bloqueios: <literal>emul_lock</literal> usado para proteger a manipulação de <literal>linux_emuldata</literal> e <literal>emul_shared_lock</literal> usado para manipular <literal>linux_emuldata_shared</literal>. O <literal>emul_lock</literal> é um mutex bloqueador não tolerável, enquanto <literal>emul_shared_lock</literal> é um bloqueio travável <literal>sx_lock</literal>. Devido ao bloqueio por subsistema, podemos unir alguns bloqueios e é por isso que o em-find oferece o acesso sem bloqueio.
Threaded programs should be written with as little contention on locks as possible. Otherwise, instead of doing useful work the thread just waits on a lock. As a result of this, the most well written threaded programs show little locks contention. Os programas em threading devem ser escritos com o mínimo de contenção possível em bloqueios. Caso contrário, em vez de fazer um trabalho útil, a threading apenas espera em um bloqueio. Devido a isso, os programas encadeados mais bem escritos mostram pouca contenção de bloqueios.