Change Instance

HTTP 200 OK
Allow: GET, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

{
    "unit": "https://translate-dev.freebsd.org/api/units/26553/?format=api",
    "component": "https://translate-dev.freebsd.org/api/components/freebsd-doc/articles_linux-emulation/?format=api",
    "translation": "https://translate-dev.freebsd.org/api/translations/freebsd-doc/articles_linux-emulation/es/?format=api",
    "user": "https://translate-dev.freebsd.org/api/users/Aaron/?format=api",
    "author": "https://translate-dev.freebsd.org/api/users/Aaron/?format=api",
    "timestamp": "2020-12-17T19:31:09.729930Z",
    "action": 5,
    "target": "Los subprocesos necesitan algún tipo de sincronización y <trademark class=\"registered\">POSIX</trademark> proporciona algunos de ellos: mutex para exclusión mutua, bloqueos de lectura y escritura para exclusión mutua con una proporción sesgada de lecturas y escrituras y variables de condición para señalar un cambio de estado. Es interesante notar que<trademark class=\"registered\">POSIX</trademark> La API de subprocesos carece de soporte para semáforos. Esas implementaciones de rutinas de sincronización dependen en gran medida del tipo de soporte de subprocesos que tenemos. En el modelo puro 1: M (espacio de usuario), la implementación se puede realizar únicamente en el espacio de usuario y, por lo tanto, es muy rápida (las variables de condición probablemente terminarán implementándose mediante señales, es decir, no rápido) y simple. En el modelo 1: 1, la situación también es bastante clara: los subprocesos deben sincronizarse utilizando las instalaciones del kernel (lo cual es muy lento porque se debe realizar una llamada al sistema). El escenario mixto M: N simplemente combina el primer y segundo enfoque o se basa únicamente en el kernel. La sincronización de subprocesos es una parte vital de la programación habilitada para subprocesos y su rendimiento puede afectar mucho al programa resultante. Pruebas de rendimiento recientes en el sistema operativo FreeBSD mostraron que una implementación mejorada de sx_lock produjo un 40% de aceleración en <firstterm>ZFS</firstterm> (un usuario pesado de sx), esto es algo dentro del kernel pero muestra claramente cuán importante es el rendimiento de las primitivas de sincronización.",
    "id": 93243,
    "action_name": "New translation",
    "url": "https://translate-dev.freebsd.org/api/changes/93243/?format=api"
}