Sort of. Basically you have a situation where one thread needs to see another thread's memory accesses in sequential consistent order. If you can determine the other thread has synchronized its memory accesses at some point, then all its memory accesses before that are in observably sequentially consistent.
The thing is you don't know exactly when that synchronization took place so your code logic has to take that into account. In the case of hazard pointers, false positives are ok and false negatives, i.e. thread is using reference that was not detected, cannot occur.
There's 2 or 3 other tricks you can make hazard pointers wait-free. Getting rid of the conditional branching in the instruction pipeline gives you a considerable speed up.
I did a POC afterwards. For linux it was a bit PITA since /proc text had to be parsed to track context switches w/ associated full MB. For Mac OS on the ppc also bit PITA since Apple tried to hide their unix api and some stuff involved calling the mach micro kernel.
Lighting rods also work by dissipating the local electric potential and reducing the likelihood of a lightning strike. That's why they are pointed, or fractal in the newer ones.
From https://en.wikipedia.org/wiki/Lightning_rod
"and that a considerable electric current can be measured through the conductors as ionization occurs at the point when an electric field is present, such as happens when thunderclouds are overhead."
You can get a ground charge even when thunderclouds aren't present. It just has to be windy. I've always wondered if it was worth collecting this, say with a field with a grid of interconnected lightning rods in a windy location.
Couldn't traceroute run the entire TTL range in parallel, assuming the destination host was reachable and replies are disambiguable? I always hated waiting for traceroutes with lots of non responding routers.
My impression was LL/SC had forward progress issues due to the difficulties of preventing false sharing of the locked memory reservation region. Updates into that region would keep invalidating the lock.
I had a version of atomic* reference counting that used LL/SC on a ppc mac mini along side x86 versions using cmpxchg16b. Code used to be sourceforge before it went to the dark side.
* Std::shared_ptr and Rust ARC aren't actually atomic. You have to own a reference to do a copy. The are what POSIX calls thread-safe. With atomic reference counting, if you copy a reference, you either get a valid reference or null. Like Java references.
The comments about HFT needing tightly synchronized clocks got me thinking.
Back in the day, way back in the 80's, IBM replaced the VM with VMXA. VM could trap and emulate all the important instructions since they were privileged instructions except one, the STCK (store clock) instruction. So virtual machines couldn't set their virtual clocks so they were always in sync. VMXA used new hw features that let you set the virtual clock. You could specify an offset to the system clock. But some of IBM's biggest customers depended on all the virtual machines clocks always being in sync. So VMXA had to add an option to disallow setting the clock for specified virtual machines.
Except all of development knew how trivial it was to trap or modify the STCK's to produce a timestamp of you choosing. This was before it was common knowledge the client code should never be trusted. But nobody enlightened IBM corporate management. It was a serious career limiting move at IBM. It didn't matter if you were right. So I'm pretty sure some serious fortunes were made as a result.
So the question for HFT is; are they using and trusting client timestamps, or are the timestamps being generated on the market maker's servers? If the latter, how would the customer know?
Ok,so people use NTP to "synchronize" their clocks and then write applications that assume the clocks are in exact sync and can use timestamps for synchronization, even though NTP can see the clocks aren't always in sync. Do I have that right?
I did a lock-free MPMC ring buffer with 1 128 bit CAS and 1 64 bit CAS for enqueue and 1 64 bit CAS for dequeue. The payload is an unrestricted uintptr_t (64 bit) value so no way to avoid the 128 bit CAS in the enqueue.
Coherent cache is transparent to the memory model. So if someone trying to explain memory model and ordering mentioned cache as affecting the memory model, it was pretty much a sign they didn't fully understand what they were talking about.
I'm assuming they're using an unbounded MPMC queue. With GC you can use a lock-free queue, otherwise you have to use mutexes, or reference counting which is nearly as bad.
I did do an actual lock-free MPMC ring buffer implementation as an exercise. I used that to make blocking bounded queues using various synchronization mechanisms, mutex/condvars and eventcounts among others. The eventcount version runs about 8x faster than the mutex version.
Only using way more bits. The original IBM lock-free stack algorithm assumed 32 bits was safe because it would take 100 years for a 32 bit counter to wrap at the time. Now it's less than 1 second.
There's some Bugblatter Beast logic here. They assume that if they can't imagine a counter/pointer value reuse ever reoccurring then malicious actors won't be able to imagine it either.
Here's an idea. How about fixing the buffer overflows and lack of data sanitation that allow code injection to occur in the first place.
I did find some links to some of my old posts on restartable sequences for user space rcu. Looked into using unix signal handling but it was pretty problematic to put it mildly. Definitely something you had to implement in the kernel.
The thing is you don't know exactly when that synchronization took place so your code logic has to take that into account. In the case of hazard pointers, false positives are ok and false negatives, i.e. thread is using reference that was not detected, cannot occur.
There's 2 or 3 other tricks you can make hazard pointers wait-free. Getting rid of the conditional branching in the instruction pipeline gives you a considerable speed up.