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/documentation/booksarch-handbooksmp_index/en/?format=api",
    "source": [
        "There are several existing treatments of memory barriers and atomic instructions, so this section will not include a lot of detail. To put it simply, one can not go around reading variables without a lock if a lock is used to protect writes to that variable. This becomes obvious when you consider that memory barriers simply determine relative order of memory operations; they do not make any guarantee about timing of memory operations. That is, a memory barrier does not force the contents of a CPU's local cache or store buffer to flush. Instead, the memory barrier at lock release simply ensures that all writes to the protected data will be visible to other CPU's or devices if the write to release the lock is visible. The CPU is free to keep that data in its cache or store buffer as long as it wants. However, if another CPU performs an atomic instruction on the same datum, the first CPU must guarantee that the updated value is made visible to the second CPU along with any other operations that memory barriers may require."
    ],
    "previous_source": "",
    "target": [
        "There are several existing treatments of memory barriers and atomic instructions, so this section will not include a lot of detail. To put it simply, one can not go around reading variables without a lock if a lock is used to protect writes to that variable. This becomes obvious when you consider that memory barriers simply determine relative order of memory operations; they do not make any guarantee about timing of memory operations. That is, a memory barrier does not force the contents of a CPU's local cache or store buffer to flush. Instead, the memory barrier at lock release simply ensures that all writes to the protected data will be visible to other CPU's or devices if the write to release the lock is visible. The CPU is free to keep that data in its cache or store buffer as long as it wants. However, if another CPU performs an atomic instruction on the same datum, the first CPU must guarantee that the updated value is made visible to the second CPU along with any other operations that memory barriers may require."
    ],
    "id_hash": 4667846920451657231,
    "content_hash": 4667846920451657231,
    "location": "documentation/content/en/books/arch-handbook/smp/_index.adoc:65",
    "context": "",
    "note": "type: Plain text",
    "flags": "",
    "labels": [],
    "state": 100,
    "fuzzy": false,
    "translated": true,
    "approved": false,
    "position": 9,
    "has_suggestion": false,
    "has_comment": false,
    "has_failing_check": false,
    "num_words": 183,
    "source_unit": "https://translate-dev.freebsd.org/api/units/1134178/?format=api",
    "priority": 100,
    "id": 1134178,
    "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksarch-handbooksmp_index/en/?checksum=c0c7860af76c0e0f",
    "url": "https://translate-dev.freebsd.org/api/units/1134178/?format=api",
    "explanation": "",
    "extra_flags": "",
    "pending": false,
    "timestamp": "2021-05-23T13:16:45.878095Z"
}