The following paper on the problems with non-scalable locking designs certainly explains some of the empirical (and app-dependent) behaviors observed with OpenVMS on larger Alpha and Itanium multiprocessors.
This is mostly OpenVMS on Alpha and Itanium multiprocessors, and now on x86-64 multicore designs, as VAX 9000 (Aridus) topped out at four (scalar) processors, and other later (and much more affordable, as compared with Aridus) VAX multiprocessors got to six or maybe eight processors.
In decades past, app performance on OpenVMS multiprocessors fell off pretty quickly starting around eight processors (or eight cores, more recently).
With the work that went into OpenVMS itself to break up spinlocks and to reduce related synchronization overhead, and with apps becoming more cognizant of NUMA hardware (where available), maintaining app performance on sixteen processors (cores) became more commonly feasible.
OpenVMS spinlocks are a somewhat simpler design than the ticket spinlocks Linux is currently using, too.
But somewhere along the path of adding more processors to scale app performance, Cache Coherency and Amdahl’s Law do come to visit, and performance craters.
@jfmezei Spinlocks, bitlocks, and interlocked queues are underneath most everything within OpenVMS.
The lock manager, the distributed transaction manager, and asynchronous system traps (ASTs) all synchronize their critical paths with these same primitives.
Apps and other OpenVMS services then use the locks provided by the lock manager for coordination, and ASTs for some (limited) asynchronous processing.
ASTs are a subset of threading, where a single process can have at most two threads (mainline non-AST-mode, and AST mode), and only one of these two can be active at a time. ASTs are fundamentally tied to a processor, as well. I’ve done a lot of AST-driven apps, particularly those using hibernation.
An aside for bug avoidance (read: learn from my mistakes): If you chose the AST-driven $hibernation/$wake design (which works very well), do remember to also issue a $schdwk scheduled wakeup call to un-stick a potentially stuck app, should a $wake call get lost somewhere. Multiple parallel $wake calls will get coalesced into one, and of course $wake calls can arrive at any time, among other wrinkles. Having a periodic wakeup call will unstick any potential race conditions.
Contrast ASTs with OpenVMS KP threads (KP threads are the underpinnings of pthreads), which allow the same app and its address space to be scheduled across multiple processors entirely in parallel.
if you’re interested in threading and such, also have a look at Apple GCD / libdispatch and blocks, as well:
I very much would have liked to have had something GCD-like available on OpenVMS, having implemented similar queued designs (absent blocks, which are also tied into compiler support) on many occasions.
How about if we take some time off from talking about Threads (TM) the Instagram/Facebook/Meta App, and instead talk about the best #interfaces for displaying and building a conversation #thread on the internet?
The upshot of the #threading interface that Mastodon inherited from Twitter is that, while it is straightforward to post an essay or rant as a sequence of toots, it is not at all straightforward to follow any conversations that it generates.
A hypothetical #Mastodon client that approached #threading in the way that I suggest could take things a step further by automatically collapsing (hiding) subthreads, so that people can choose whether to view those replies (again, in place) or not.
Unfortunately, trying to organize a Mastodon thread with all toots as replies to a single top-level toot results in an incoherent thread view on the default web client and (as far as I know) all other existing clients.
So, in our current world, in which conversation platforms are accessed by diverse clients, there are real barriers to client diversity in how #threading is handled.
This isn't just a #Fediverse issue, but applies to any protocol that can be accessed through independently developed clients.
The one I've used the most, @tooot, has become glitchy and slow, and doesn't have everything I want, but was the best so far.
I paid for @tootapp, which is also not feature-complete for my preferences, and the dev posted soon after I paid that they're too busy/disinterested to accept or implement user requests (wtaf?)
This app may be most feature complete (threading?)
Fuck me, MS #Teams has never been a great product but forcing channels to sort newest to oldest while chats stay oldest to newest is a new low. And no option to turn it the fuck off. 🙄
So it sure looks like #Reddit is going to eat itself in the next week or so. The recent AMA from the CEO pretty much shows they are going the Twitter route. Trying to monetize a platform in a way that's going to drive the users away from it.
I had hoped that #Mastodon would be the thing that could replace both Reddit and Twitter, but without a federated #groups model, or proper #threading, or similar tools, it's not going to work.