AuroraRuntime/Media/AuRWLock Ordering.txt

16 lines
1.4 KiB
Plaintext
Raw Normal View History

2023-09-17 19:26:21 +00:00
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
2024-05-28 17:56:20 +00:00
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.
2023-11-15 15:51:54 +00:00
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.
2023-09-17 19:26:21 +00:00
2024-05-28 17:56:20 +00:00
"./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...