Stroika::Foundation::Execution::SpinLock Class Reference

#include <SpinLock.h>

Public Types
enum class	BarrierType

Public Member Functions
	SpinLock (BarrierType barrier=BarrierType::eDEFAULT)

Detailed Description

Implementation based on http://en.cppreference.com/w/cpp/atomic/atomic_flag

About to run tests to compare performance numbers. But this maybe useful for at least some(many) cases.

Note

- SpinLock - though generally faster than most mutexes for short accesses, are not recursive mutexes!

Not Cancelation Point SpinLock contains no cancelation points, and so can be used interchangeably with mutex - just for the performance differences

From http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3690.pdf 1.10 Multi-threaded executions and data races [intro.multithread]

"A synchronization operation without an associated memory location is a fence and can be either an acquire fence, a release fence, or both an acquire and release fence"

Since a spinlock once acquired - can be used to assume assocated data (the data protected by the spinlock mutex) is up to date with respect to other threads and acquire is needed on the lock. And to assure any changes made with the lock are seen in other threads a release atomic_fence() is required on the unlock.

This is the DEFAULT behavior we provide with the default BarrierType - eReleaseAcquire

Note

More good references (to verify if this logic is right - which I'm not 100% clear on) o https://www.boost.org/doc/libs/1_54_0/doc/html/atomic/usage_examples.html#boost_atomic.usage_examples.example_spinlock o https://blog.regehr.org/archives/2173 This strongly suggests I may want to do a more fair spinlock, but doesn't appear to have the fences. In fact, he alleges if you do procedure properly you dont need the fence. HMM. Need good test cases before I can really play around with this very safely.

Definition at line 62 of file SpinLock.h.

Member Enumeration Documentation

BarrierType

enum class Stroika::Foundation::Execution::SpinLock::BarrierType

strong

See also

std::atomic_thread_fence ()

std::memory_order

Note

subtly - eReleaseAcquire means acquire on lock, and release on unlock. This is the natural default for a mutex.

Definition at line 70 of file SpinLock.h.

Constructor & Destructor Documentation

SpinLock()

Stroika::Foundation::Execution::SpinLock::SpinLock

(

BarrierType

barrier = BarrierType::eDEFAULT

)

In typical usage, one would use a SpinLock as a mutex, and expect it to create a memory fence. However, sometimes you want to spinlock and handle the memory ordering yourself. So that feature is optional (defaulting to the safer, but slower - true).

Definition at line 13 of file SpinLock.inl.

---

The documentation for this class was generated from the following files:

• SpinLock.h
• SpinLock.inl