Reader and writer threads are kept separate in separate queues. No wake operation for many-readers will result in a spurious wake of a writer thread, and vice versa.
Waits/yields of write-upgrades, write-locks, and then read-locks are grouped together by identical wake characteristics defined by platform specific quirks, sorted by that respective order for the logical intentions of the abstract RWLock primitive.
"./Condvar and other reodering of thread primitives.txt" implies tickets are a waste of cycles, serving no point but to thrash contexts. They serve no logical high level value, nor provide low level performance gains.
It's just a spinlock algorithm a bunch of braindead normie boomers thought was cute.
You're telling the os to resched or perform a SMT yield because your wake wasnt good enough.
Why would you context switch again? Oh right, you'd do it to sit on the exact same physical core (0-12? 0-16? out of hundreds/thousands of contexts?), most likely thrashing cache in a switch, to dequeue a high level context to perform the exact same queued up work - but with different TLS indicies!!!
...something something im abusing condvars and mutexes as timeline barriers for garbage code. okay...
