spin lock

[thompsonbry]

You mentioned an issue with the use of _mm_pause in the spin lock implementation here. We've been using a variant of this spin lock

// spin_lock code is taken from: https://rigtorp.se/spinlock/

| | // modified to handle ARM
| | struct spin_lock_t {
| | std::atomic lock_ = {0};
| |
| | void lock() noexcept {
| | for (;;) {
| | // Optimistically assume the lock is free on the first try
| | if (!lock_.exchange(true, std::memory_order_acquire)) {
| | return;
| | }
| | // Wait for lock to be released without generating cache misses
| | while (lock_.load(std::memory_order_relaxed)) {
| | cpu_acquiesce();
| | }
| | }
| | }
| |
| | bool try_lock() noexcept {
| | // First do a relaxed load to check if lock is free in order to prevent
| | // unnecessary cache misses if someone does while(!try_lock())
| | return !lock_.load(std::memory_order_relaxed) &&
| | !lock_.exchange(true, std::memory_order_acquire);
| | }
| |
| | void unlock() noexcept {
| | lock_.store(false, std::memory_order_release);
| | }
| | }; // spin_lock_t

[laurynas-biveinis]

Will you be able to get by with a pure spinlock for locking? Without putting the thread to sleep after some spinning?

[thompsonbry]

Likely. All structural mutation operations should be very fast. And we can allocate before we lock. Allocation is much of the time unless we have a lightweight pool. We generally do something more like ROWEX and I can help work through what that might look like as we get further along, though it offered no benefit in their testing. Templating the lock strategy and the key structure would both seem to increase flexibility. Bryan

…

On Mon, Nov 25, 2024 at 10:47 Laurynas Biveinis ***@***.***> wrote: Will you be able to get by with a pure spinlock for locking? Without putting the thread to sleep after some spinning? — Reply to this email directly, view it on GitHub <#605 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AATW7YHERK2EORELU6NIMQD2CNBBPAVCNFSM6AAAAABSJY567GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJYGM4DCMJYGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>