tearor provides the TearCell, a (barely) thread-safe lock-free cell
type providing tearing access to any type which is Pod.
Tearing access refers to when multiple smaller, separate read or write operations are used to perform a larger unit of work. For example, if you wrote to a &mut u32 by performing 4 writes, one to each byte, or vice-versa.
TearCell uses the same idea, but with atomics. If your T is too large to
fit inside an atomic, then TearCell will split it over a few operations.
Needless to say, this means calls to TearCell::load, TearCell::store,
(etc) are not atomic (nor do they provide any guarantees about
ordering), however every individual operation the TearCell performs is
atomic (with the weakest ordering we can get our hands on), which is enough
to avoid data races.
It's essentially a tool for turning data races into data corruption. If the
lack of synchronization would cause a data race (e.g. with UnsafeCell), then
TearCell is very likely to corrupt your data.
However, if this does not matter to you for one reason or another (examples:
your synchronization is performed externally, you want to perform an
optimistic read, all threads are writing the same value, or you miss the fun
you had debugging data corruption issues in C++), then TearCell might be
what you want.
Public domain, as explained here