Unit Instance

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

{
    "translation": "https://translate-dev.freebsd.org/api/translations/freebsd-doc/articles_linux-emulation/en/?format=api",
    "source": [
        "Threads need some kind of synchronization and <trademark class=\"registered\">POSIX</trademark> provides some of them: mutexes for mutual exclusion, read-write locks for mutual exclusion with biased ratio of reads and writes and condition variables for signaling a status change. It is interesting to note that <trademark class=\"registered\">POSIX</trademark> threading API lacks support for semaphores. Those synchronization routines implementations are heavily dependant on the type threading support we have. In pure 1:M (userspace) model the implementation can be solely done in userspace and thus be very fast (the condition variables will probably end up being implemented using signals, i.e. not fast) and simple. In 1:1 model, the situation is also quite clear - the threads must be synchronized using kernel facilities (which is very slow because a syscall must be performed). The mixed M:N scenario just combines the first and second approach or rely solely on kernel. Threads synchronization is a vital part of thread-enabled programming and its performance can affect resulting program a lot. Recent benchmarks on FreeBSD operating system showed that an improved sx_lock implementation yielded 40% speedup in <firstterm>ZFS</firstterm> (a heavy sx user), this is in-kernel stuff but it shows clearly how important the performance of synchronization primitives is."
    ],
    "previous_source": "",
    "target": [
        "Threads need some kind of synchronization and <trademark class=\"registered\">POSIX</trademark> provides some of them: mutexes for mutual exclusion, read-write locks for mutual exclusion with biased ratio of reads and writes and condition variables for signaling a status change. It is interesting to note that <trademark class=\"registered\">POSIX</trademark> threading API lacks support for semaphores. Those synchronization routines implementations are heavily dependant on the type threading support we have. In pure 1:M (userspace) model the implementation can be solely done in userspace and thus be very fast (the condition variables will probably end up being implemented using signals, i.e. not fast) and simple. In 1:1 model, the situation is also quite clear - the threads must be synchronized using kernel facilities (which is very slow because a syscall must be performed). The mixed M:N scenario just combines the first and second approach or rely solely on kernel. Threads synchronization is a vital part of thread-enabled programming and its performance can affect resulting program a lot. Recent benchmarks on FreeBSD operating system showed that an improved sx_lock implementation yielded 40% speedup in <firstterm>ZFS</firstterm> (a heavy sx user), this is in-kernel stuff but it shows clearly how important the performance of synchronization primitives is."
    ],
    "id_hash": -5533858468812540047,
    "content_hash": -5533858468812540047,
    "location": "article.translate.xml:1976",
    "context": "",
    "note": "(itstool) path: sect3/para",
    "flags": "",
    "labels": [],
    "state": 100,
    "fuzzy": false,
    "translated": true,
    "approved": false,
    "position": 288,
    "has_suggestion": false,
    "has_comment": false,
    "has_failing_check": false,
    "num_words": 198,
    "source_unit": "https://translate-dev.freebsd.org/api/units/99685/?format=api",
    "priority": 100,
    "id": 99685,
    "web_url": "https://translate-dev.freebsd.org/translate/freebsd-doc/articles_linux-emulation/en/?checksum=3333c90ad1243771",
    "url": "https://translate-dev.freebsd.org/api/units/99685/?format=api",
    "explanation": "",
    "extra_flags": "",
    "pending": false,
    "timestamp": "2019-10-20T12:10:41.260638Z"
}