Defer to ThreadingConfig::bEnableRWLockWriteBiasOnReadLock

When true
	Reader availability is starved as soon as there is a writer waiting

When false
	Readers can starve pending write waiters

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...