Chris's Wiki :: blog/programming/CaseForAtomicTypes Commentshttps://utcc.utoronto.ca/~cks/space/blog/programming/CaseForAtomicTypes?atomcommentsDWiki2023-03-15T12:00:07ZRecent comments in Chris's Wiki :: blog/programming/CaseForAtomicTypes.By jonys on /blog/programming/CaseForAtomicTypestag:CSpace:blog/programming/CaseForAtomicTypes:7db58b799bf47eb5c28d89755961d3c4ba5b8d99jonys<div class="wikitext"><p>The other major issue with the "atomic operation, not atomic type" view is portability – CPU and system architectures differ wrt. which types support which atomic operations, and when a particular type isn't supported (e.g. 64b atomic data access on 32b archs), the "atomic type" approach allows emulation of atomicity using attached locks. If you use an atomic op on a non-atomic type, there is no space to put the lock into.</p>
</div>2023-03-15T12:00:07ZBy Andrew on /blog/programming/CaseForAtomicTypestag:CSpace:blog/programming/CaseForAtomicTypes:e956545eb58eb784dd29dc630e4b239ebc626eb9Andrew<div class="wikitext"><p>You could also say "integers aren't signed or unsigned inside the computer; multiplies and divides (and some loads and stores) are." But C has signed and unsigned integral types anyway.</p>
</div>2023-02-14T02:21:29Z