Friday, October 1, 2021

Digest for comp.lang.c++@googlegroups.com - 4 updates in 1 topic

Branimir Maksimovic <branimir.maksimovic@icloud.com>: Oct 01 08:53PM

> latter might have to wait.
 
> This even works for wait-free structures. In this case, the fast-path would
> be wait-free.
 
Watch out that "wait free" isn't just spining with more cpomplex algorithm
doing nothing usefull :P
here is mine mutex:
format elf64
 
FUTEX_WAIT equ 0
FUTEX_WAKE equ 1
FUTEX_PRIVATE_FLAG equ 128
 
public futex_acquire
public futex_release
 
futex_acquire:
push rbx
push r15
; push r10
mov r15,rdi
.L0:
mov ebx,1
xor eax,eax
lock cmpxchg [r15],ebx
test eax,eax
jz .L1
mov eax, 202
mov rdi, r15
mov rsi, FUTEX_WAIT or FUTEX_PRIVATE_FLAG
mov edx, 1
xor r10,r10
syscall
jmp .L0
.L1:; pop r10
pop r15
pop rbx
ret
 
futex_release:
lock and dword[rdi],0
mov eax,202
; mov rdi, sema
mov rsi, FUTEX_WAKE or FUTEX_PRIVATE_FLAG
mov edx,1
syscall
ret
 
>> Lock-free and wait-free datastructures are idiocracy except from lock-free
>> stacks.
 
> Sure. Whatever you say Bonita. Cough.... Cough... ;^)
Heh, rsyncing something, looking bloat and have no patience :p
 
 
--
 
7-77-777
Evil Sinner!
Branimir Maksimovic <branimir.maksimovic@icloud.com>: Oct 01 08:54PM

>> An error occurred. Please try again later. (Playback ID: pHR4vgIqqp13ECHz)
>> Learn More
 
> That's odd. The links I posted work for me. Just checked them. Humm...
Safari, iCloud private relay.... ipv6
 
--
 
7-77-777
Evil Sinner!
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 01 02:24PM -0700

On 10/1/2021 1:53 PM, Branimir Maksimovic wrote:
>> be wait-free.
 
> Watch out that "wait free" isn't just spining with more cpomplex algorithm
> doing nothing usefull :P
 
True! Imvvvho, wait-free should be loopless. Now, I always got nervous
over trying to implement wait-free with LL/SC, an optimistic atomic
primitive. I prefer to implement them using pessimistic atomic ops like
an atomic exchange or fetch-and-add. However, then again atomic exchange
can be implemented by LL/SC, or CAS. This is not Kosher in my mind.
Quite fond of the pessimistic x86 XADD or XCHG atomic OPS when it comes
to wait-free because there is no looping involved. Actually, CAS in x86
can be used for a state machine without looping because it always
returns a result. If CAS on x86 fails we have the reason why. This is
different than LL/SC that can spuriously fail.
 
 
 
> mov edx,1
> syscall
> ret
 
Need to look at it, should work. Fwiw, here is an example using a futex
on windows. Yes it actually has one, lol! Btw, this is using XCHG only.
______________________________________
#include <iostream>
#include <thread>
#include <functional>
 
#define WIN32_LEAN_AND_MEAN
#include <Windows.h>
 
 
#define CT_L2_ALIGNMENT 128
#define CT_THREADS 32
#define CT_ITERS 6666666
 
 
struct ct_futex_mutex
{
ULONG alignas(CT_L2_ALIGNMENT) m_state;
 
ct_futex_mutex() : m_state(0)
{
 
}
 
void lock()
{
if (InterlockedExchange(&m_state, 1))
{
while (InterlockedExchange(&m_state, 2))
{
ULONG cmp = 2;
WaitOnAddress(&m_state, &cmp, sizeof(ULONG), INFINITE);
}
}
}
 
void unlock()
{
if (InterlockedExchange(&m_state, 0) == 2)
{
WakeByAddressSingle(&m_state);
}
}
};
 
 
struct ct_shared
{
ct_futex_mutex m_mtx;
unsigned long m_count;
 
ct_shared() : m_count(0) {}
 
~ct_shared()
{
if (m_count != 0)
{
std::cout << "counter is totally fubar!\n";
}
}
};
 
 
void ct_thread(ct_shared& shared)
{
for (unsigned long i = 0; i < CT_ITERS; ++i)
{
shared.m_mtx.lock();
++shared.m_count;
shared.m_mtx.unlock();
 
shared.m_mtx.lock();
--shared.m_count;
shared.m_mtx.unlock();
}
}
 
 
int main()
{
std::thread threads[CT_THREADS];
 
std::cout << "Starting up...\n";
 
{
ct_shared shared;
 
for (unsigned long i = 0; i < CT_THREADS; ++i)
{
threads[i] = std::thread(ct_thread, std::ref(shared));
}
 
std::cout << "Running...\n";
 
for (unsigned long i = 0; i < CT_THREADS; ++i)
{
threads[i].join();
}
}
 
std::cout << "Completed!\n";
 
return 0;
}
______________________________________
 
 
;^)
 
>>> stacks.
 
>> Sure. Whatever you say Bonita. Cough.... Cough... ;^)
> Heh, rsyncing something, looking bloat and have no patience :p
 
;^)
Branimir Maksimovic <branimir.maksimovic@icloud.com>: Oct 01 10:13PM

> }
> }
> };
 
Same thing practically, except linux futex, which is same thing.
Interrestingly Darwin does not have it and I am really interrested
how Apple immplements pthread_mutex?
 
--
 
7-77-777
Evil Sinner!
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.

No comments: