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

[*] Update AuRWLock Ordering.txt

Browse Source
This commit is contained in:
Reece Wilson 2023-11-15 15:51:54 +00:00
parent 0bcdb46d72
commit e3cecc2d35
1 changed files with 11 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
Media/AuRWLock Ordering.txt
View File

@ -7,19 +7,17 @@ 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.
Reader and writer threads are generally kept separate. 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.
To reiterate, only WakeOnAddress in emulation mode is guaranteed to have FIFO Wait/an order of thread wake-ups - that's to say tickets or prio-wake-queue aren't used to enforce access order.
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 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, 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!!!
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.
...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?
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 program like Python or Lua.
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 fiber #45345 doesn't idle or spin a bit more than fiber #346.
Arguably, if you're trying to "optimize" thread primitives with tickets and in-process scheduling, and not high level descriptions of what the synchronization primitive is doing in the context of its use case and the platform it runs on, you're a fucking idiot.
Any other scheduling leg-work should be the responsibility of the kernel and perhaps a chipset vendor driver being aware of system-wide thread priorities+tasks; you are not faster or smarter than a generic interface and the kernel/os doing one of its rudimentary responsibilities.