Thanks, Mark, I will send you two commits as requested. Thanks again for all your help!

Reformat to ahere to suggested style...

Refactor to more closely follow seqc.h.

Updated to quasi-follow seqlock semantics from seqc.h for continued discussion...

In D41150#938121, @kib wrote:

With tail pad, I mean the following. The goal of the exercise is not to get specific alignments, but ultimately ensure that lock objects do not (false) share cache lines with any other objects. Alignment ensures that there is no sharing with

So now I am wondering if __crt_aligned_alloc() should be abandoned. Other cleanup from this review should go in, IMO.

Are you saying that instead of aligning pthread_mutex allocations, we just need to ensure that allocation is padded to the end of the cache line? Then, perhaps the same thing needs to be done to rwlocks and spinlocks?

Fix how generation count is updated and synchronized with readers.
Add comments to explain how it works.

General observation. Overall I like this new feature! But I have a suspicion that using it for pthread mutexes might increase the lock/unlock latency a wee bit.

General question: AFAICT, on amd64 _ _crt_malloc() seems to always return an address that is a power-of-two + 8 bytes. Why isn't it at least _ _alignof(max_align_t) aligned?
For example, it appears that malloc(3) always returns a suitably aligned allocation as long as the request is for more than 8 bytes.

Use MACHINE_ABI to build only for 64-bit architectures.
Replace uint64_t with u_long for pshared hash table generation counts.

I reverted all the m_qidx changes, lost a wee bit of perf across all mutex flavors, but numbers still look pretty good.

Updated diff to provide full context via diff -U99999999 ...

Thanks John, I've updated the patch as requested, including the tools/build/options change (I wasn't aware of that, pretty cool!)