AuroraSupport/AuroraRuntime
2
1
Fork 0
Code Issues 27 Pull Requests Releases Wiki Activity

[+] AuRWLock Ordering.txt

Browse Source
This commit is contained in:
Reece Wilson 2023-09-17 20:26:21 +01:00
parent 7a5d1cd396
commit c5a2d1e582
1 changed files with 25 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
Media/AuRWLock Ordering.txt Normal file
View File

@ -0,0 +1,25 @@
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
Much like other Aurora primitives, there is no guarantee of order.
However, readers and writers are generally kept separate. No internal wake operation for many-readers will result in a spurious wake of a writer thread, and vice versa.
Write-upgrades, generic write-waits, and then reads are grouped together by identical wake characteristics defined by platform specific quirks, sorted by the respective logical order for the high level primitive.
But as initially stated and outlined everywhere else else, only WakeOnAddress in emulation mode is guaranteed to have FIFO Wait/Wake order, that's to say tickets aren't used to enforce an order of stupid high level fibers/thread contexts here.
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 normies thought was cute.
*: you are telling the os to resched or perform a SMT yield because your wake wasnt good enough. why would you context switch again? oh right, to sit on the exact same physical core (0-12? 0-16? out of hundreds/thousands of contexts?), or perhaps likely thrash cache in a switch, to dequeue a high level context to perform the exact same high level work.
you would be hard-pressed to make a convincing argument against this perspective...
...that's unless you're stuck in the bygone-era of native fibers, async io routines, and the likes, oh shit we're going back in time with meme-langs and runtimes again aren't we?
I know this tangent will be a bit of a shock to boomers and zoom zooms, but fibers suck and any developer that touched NT fibers or system admin that enabled SQL-server fibers regretted it.
They objectively ruin your latency, make it harder to code for, and make managing the life time of resources a pain in the ass.
They subjectively result in terrible high level applications with buggy interfaces, no real threading model, no sense of asset loading and prefetch, no sense of data caching, or much of the like.
Instead, you get babies (or NIX boomers) first application where they expect everything to magically happen on a fork or dynamically scaled thread pool, with no feel for the global application architecture and state.
They're more akin to a hack to support babiest first "while (!bSocketError) { accept(); CreateThread(); }" server than an answer to any real problem. A third/fourth level of indirection of a thread context (physical core -> (hyperthread ->) software/kernel switchable context -> abstract userland schedulers' context) makes very little sense, past making these instances of shit-code suck less.
Arguably, fibers and async routines are at best a hack for naive developers who don't think about what their program is doing... or at best a hack for a single-threaded interpreter.
Arguably, optimizing thread primitives with tickets serves no purpose other than to optimize fiber-iq code, where half-assed FIFO and monte carlo guarantees aren't good enough to ensure fibre #45345 doesn't idle or spin a bit more than fiber #346.
Arguably, if you're trying to optimize thread primitives with tickets and not high level descriptions of what the synchronization primitive is doing, you're a fucking idiot.