I'd be interested how feasible complete 2D UIs using dynamically GPU rendered vector graphics are. I've played with vector rendering in the past, using a pixel shader that more or less implemented the method described in the OP. Could render the ghost script tiger at good speeds (like 1-digit milliseconds at 4K IIRC), but there is always an overhead to generating vector paths, sampling them into line segments, dispatching them etc... Building a 2D UI based on optimized primitives instead, like axis-aligned rects and rounded rects, mostly will always be faster, obviously.

Text rendering typically adds pixel snapping, possibly using byte code interpreter, and often adds sub-pixel rendering.

This article does clip against a square pixel’s edges, and sums the area of what’s inside without weighting, which is equivalent to a box filter. (A box filter is also what you get if you super-sample the pixel with an infinite number of samples and then use the average value of all the samples.) The problem is that there are cases where this approach can result in visible aliasing, even though it’s an analytic method.

When you want high quality anti-aliasing, you need to model pixels as soft leaky overlapping blobs, not little squares. Instead of clipping at the pixel edges, you need to clip further away, and weight the middle of the region more than the outer edges. There’s no analytic method and no perfect filter, there are just tradeoffs that you have to balance. Often people use filters like Triangle, Lanczos, Mitchell, Gaussian, etc.. These all provide better anti-aliasing properties than clipping against a square.

Computing pixel coverage accurately isn't enough for the best results. Using it as the alpha channel for blending forground over background colour is the same thing as sampling a box filter applied to the underlying continuous vector image.

But often a box filter isn't ideal.

Pixels on the physical screen have a shape and non-uniform intensity across their surface.

RGB sub-pixels (or other colour basis) are often at different positions, and the perceptual luminance differs between sub-pixels in addition to the non-uniform intensity.

If you don't want to tune rendering for a particular display, there are sometimes still improvements from using a non-box filter

An alternative is to compute the 2D integral of a filter kernel over the coverage area for each pixel. If the kernel has separate R, G, B components, to account for sub-pixel geometry, then you may require another function to optimise perceptual luminance while minimising colour fringing on detailed geometries.

Gamma correction helps, and fortunately that's easily combined with coverage. For example, slow rolling tile/credits will shimmer less at the edges if gamme is applied correctly.

However, these days with Retina/HiDPI-style displays, these issues are reduced.

For example, MacOS removed sub-pixel anti-aliasing from text rendering in recent years, because they expect you to use a Retina display, and they've decided regular whole-pixel coverage anti-aliasing is good enough on those.

    foo->bar.baz

    foo.bar.baz

Performance is mostly a consequence of clear and direct code. You mostly don't achieve performance by saving individual copies, but by being in control of the code and architecture.

Elsewhere in the arstechnica comments you linked

> But, uh... this isn't a "Linus Torvalds is a jerk" sort of situation. "Controversial" undersells just how outlandish and inappropriate Blow's views are. Blow is a full-bore fascist sympathizer who also doesn't seem to think that women have any role to play in his profession.

What's going on on these platforms? Is there any serious evidence to the strong claims?

[1]: https://www.redditmedia.com/r/SubredditDrama/comments/1jh275...

> If a state entity does an oopsie in a lab, then forces its citizens to undergo an experimental treatment because of the oopsie, while suppressing news of side effects, and also denying that the oopsie is anyone's fault ... that's just abusive?

Unfortunately Blow was unwilling to come out and state his position here, relying instead on innuendo, so we have to kind of guess what he was trying to say. I interpret him as making four claims here:

1. The COVID-19 pandemic originated in a lab leak.

2. Some Chinese people were forced to accept experimental vaccinations.

3. The government of the PRC suppressed news of the side effects of the vaccines.

4. The government of the PRC worked to prevent investigations into the cause of the pandemic.

Claim #4 is plainly true; the WHO and several other countries have protested this at great length.

Claim #2 probably depends on your threshold for "experimental" and "forces". https://en.wikipedia.org/w/index.php?title=Sinopharm_BIBP_CO... explains that emergency vaccination was available in China in July 02020, and there are plausible claims that Chinese state employees and students traveling abroad were required to take it. This was before results were in from clinical trials, which I think qualifies for most people's definition of "experimental"; the WHO wouldn't add it to its list of authorized emergency vaccines until May of the next year.

Claim #3 seems almost guaranteed to be true, but I don't have direct evidence. The government of the PRC routinely suppresses news, and there are numerous well-documented instances of this happening in connection with COVID, and there are always some subjects in clinical trials of vaccines who have major health problems such as death which may or may not be caused by the vaccine. BBIBP-CorV seems to have been, in the end, pretty safe, but it seems inconceivable that there weren't at least some news of people dying or having terrible health problems after receiving it which were deleted from Weibo or other media ("suppressed"), and that these deletions were carried out because of state policy of the PRC.

Claim #1 seems like the most debatable one, but even that isn't an open-and-shut case. At the time, the lab-leak case was fairly weak, and it certainly hasn't been proven, but it hasn't been disproven either; see https://www.astralcodexten.com/p/practically-a-book-review-r... for an extensive summary of the debate. Because of the truth of Claim #4 it seems unlikely that it will ever be disproven.

More generally, I find deplorable the polarization on partisan political grounds of fields like puzzle games, genetics, and quantum physics. Artistic development, understanding the world, and extending technology are necessarily collaborative endeavors, and rejecting Blow's games because he criticizes the Chinese government seems akin to refusing to use the Schrödinger equation because Schrödinger sexually victimized teenage girls.

I think you are taking a very charitable view here - the tweet immediately before the one you quote is clearly talking about the US vaccine mandate (not China).

> There's a weird disconnect in this vaccine mandate debate: many are still pretending that Covid-19 is of natural origin, which gives such mandates a different feel than they otherwise have.

Contrary to your assertion, this is not clearly talking about vaccine mandates in any particular place. And the tweet I quoted previously is claiming (or hinting) that the same "state entity" had caused the pandemic and mandated the "experimental treatment". I'm not familiar with any versions of the lab-leak hypothesis that claimed that covid escaped from a US lab, so I don't think it's a reasonable inference that he's talking about the US vaccine mandate.

On the other hand, he seems to have worked pretty hard to avoid clearly stating any of his positions here, so who knows what he really thinks? Or thought?

Their covid vaccine program was voluntary up until they tried to establish a mandate in July of '22 (a lot of commentators seem to be confused on this point, as there are mandates for childhood vaccines in China - but these never extended to covid vaccines)

I think he is the latest victim of the Notch-Rowling slide into rightism. It happens when a relatively benign conservatives have opinions that get the internet mob riled up, bullies them, cancels them and thus makes them dig deeper into their righitst believes and moving more and more into hating said mob, extending that hate to the people the mob pretends to represent, etc. It's a bit sad really. I hope he'll come out of it some day, but in my experience he doesn't have the humility of accepting when he's wrong.

I say that as someone who once made him angry myself when I live-commented in one of his streams because I had a rare disagreement. I was maybe not in shock but at least startled by his reaction. I had presented my disagreement relatively casually.

Now, my impression is that he's tuned down his considerably and developed a more well meaning stance on things over the years. Recently I've found him more on the side of "here's how most people are doing this, I don't like this, maybe I don't think it's sustainable or how you get good results, but anyway here's what I like to do instead, make of it what you want".

I'm not a US citizen, but being enthusiastic about other people losing their freedom and freedoms is obscene.

I don't know, but I doubt it. He's too well adjusted at being social (his hobbies have him interact with people on the regular, and he's streaming on twitch, and doing public speaking at conferences) for me to think that.

Can it really be considered “relatively benign” when an extremely famous public figure is calling for people who disagree with them to be shot?

I can't speak for Blow, but that definitely seems to accurately describe the arc Rowling has taken over the last 7-8 years.

What a bizarre time we are living in when "men aren't women" and "women should have single-sex spaces and rape crisis centres" are considered extreme views.

Beware anyone who claims to represent "all" of some large diverse group, such as "Women" or "Floridians".

"Women should have single sex spaces" turns out to be used to justify, "It's OK to be hateful and even violent against women in these spaces so long as your excuse is that you believe they're not actually women" which is bullshit.

Years ago, when I wasn't too tired to spend all day and half the night dancing, I went to Bang Face Weekender - basically imagine a huge multi-room club night except for days and days. I keep the socials for it available because hey, it's a nice memory. This sort of "Single sex spaces" bullshit caused a problem for the last-but-one Bang Face because a new-to-this Security outfit somehow decided it's their job to go remove people who in their view weren't women from a toilet for women. These women weren't causing any problems for anybody else, but because they presumably had the wrong genitals or for some other reason were "suspect" to that Security team, Security dragged them out of a toilet cubicle and threw them out of the site. Other clubbers were of course horrified, and the event runners had to apologise to everybody - because regardless of how many X chromosomes you have, or whether you do or don't have a womb, dragging people out of the toilets because you've got weird ideas about what is or isn't a woman is batshit.

As for Bang Face last year, what happened is that security staff kicked a group of males out from the women's toilets. I agree that this isn't an ideal outcome, much better would have been if these men had respected that women's spaces are not for them, and stayed out in the first place. The fact that their removal was treated as some sort of scandal shows how far we've lost sight of the rights of women and girls to have single-sex provisions.

And yet this fact about your belief makes you so uncomfortable that you find yourself trying to pretend that somehow it's the opposite of what you believe.

I think this is letting people off the hook. We're talking about adults in their 40s and 50s here. When people like that 'suddenly' endorse extreme views it's because they had held them back and feel enabled to say them now, an adult isn't going to become an extremist because someone was mean to them online.

I'm 20 years younger than Blow and even at my age I can tell I'm settled enough psychologically that adopting radically different views would require a lot of internal effort. Views don't exist in a vacuum, to believe radical things you have to radically alter all the other things you belief. I really don't think we should people like this like children without agency.

>drives them to support much more extreme views, like what you are describing, that they otherwise might not have.

The view I mentioned was the one that got Notch (one of the public figures mentioned by GP) the reaction from the internet in the first place. A bit disingenuous to say this was a moderate conservative talking point before he got sent spiraling into a far right abyss by an angry progressive mob.

I'm not saying these people were rays of sunshine before, I'm saying they could be talked to without them foaming at the mouth and you face palming at how unhinged they were. I was using the meaning of benign attached to tumors.

I am not an expert either, if that episode occurred later than I remember, it could have been as you say.

There are people in this thread comparing Trump to Hitler. I don't think Trump is the US finest president but those of my family who weren't slaves for the Germans were slaughtered.

The fact that people throw comparisons that are false on some massive scale around and it's completely normalized is an example why losing touch with reality is not only a problem of the right

1: https://www.resetera.com/threads/jonathan-blow-the-witness-b...

It _boggles_ my mind that someone might find it controversial that there are on average differences between the sexes in terms of behaviour and interests. And to throw extremely strong accusations like "fascist" for a totally reasonable assumption or observation like that, I don't have words for that, I think those people have been smoking too much pot.

> Blow is a full-bore fascist sympathizer who also doesn't seem to think that women have any role to play in his profession.

The latter part being argued with a post where he merely opines that the sexes have different interests.

The quote does not support your point.

“It's amazing how much leftist discourse is just them pretending not to understand things, thus making discourse impossible.”

You even decry the lack of factual evidence in the critic’s case, but for some reason said nothing about Blow doing the same first.

That’s what looks silly to me. You’re not treating them the same.

Which I’m not doing.

I even explicitly said I never encountered that claim before. As such, I’m not going to do very stupid armchair expert thing I’m criticising and comment on it. The points I made are on the things I know and reflected on, not on superficial information received three minutes ago.

I'm impressed with how well you summarized my thoughts about him. I vaguely recall having this impression about him after I read his technical article (can't remember the topic) and decided that I don't think I need to read more from someone that comes through as an asshole. This was around the time The Witness came out, I'm quite happy that I didn't have to witness (hah!) what sounds like his further slide into the madness.

The idea that the data model looks like

   enum XYZ {
      case A(B, C, D, E);
      case F(G, H, I, J, K);
      case L();
      case M(N, O);
   }

I think messaging is one case where it can happen, but even there it's often good to combine fields and share them (and common code) over multiple types of messages. If Messages A and B both have a field "creationTime" or whatever (with identical semantics), it's probably a bad idea to model them as separate fields, because that leads to code duplication, which is unmaintainable.

Maybe I can be more precise by proclaiming that ADTs can be good to be clear what's "there", so they can be used to "send" information. But to write any useful usage code, typically a different representation that folds common things into common places is needed. And it might just happen that field F is valid in cases A and B but not C. That's life! Reality is not a tree but a graph.

That's why it's a bad idea to try and model the exact set of possible states and rule out everything else completely in the type system. Even the most complicated type systems can only deal with the simple cases, and will fail and make a horrible mess at the more complicated ones.

So I'm saying, there is value to preventing some misuse and preventing invalid states, but it comes at a cost that one has to understand. As so often, it's all about moderation. One should avoid fancy type system things in general because those create dependency chains throughout the codebase. Data, and consequently data types (including function signatures) is visible at the intersection of modules, so that's why it's so easy to create unmaintainable messes by relying on type systems too much. When it's possible to make a usable API with simple types (almost always), that's what you should do.

Actually, I have some similar concerns about powerful type systems in general -- not just OOP. Obsessing about expression and enforcement of invariants on the small scale can make it hard to make changes, and to make improvements on the large scale.

Instead of creating towers of abstraction, what can work better often is to try and structure things as a loosely coupled set of smaller components -- bungalows when possible. Interaction points should be limited. There is little point in building up abstraction to prevent every possible misuse, when dependencies are kept in check, so module 15 is only used by 11 and 24. The callers can easily be checked when making changes to 15.

But yeah -- I tend to agree with GP that immutability is a big one. Writing things once, and making copies to avoid ownership problems (deleting an object is mutation too), that prevents a lot of bugs. And there are so many more ways to realize things with immutable objects than people knew some time ago. The typical OOP codebase from the 90s and 00s is chock-full with unnecessary mutation.

Could you please expand upon your idea, particularly the idea that creating (from what I understood) a hierarchical structure of "blackboxes" (abstractions) is bad, and perhaps provide some examples? As far as I understand, the idea that you compose lower level bricks (e.g. classes or functions that encapsulate some lower level logic and data, whether it's technical details or business stuff) into higher level bricks, was what I was taught to be a fundamental idea in software development that helps manage complexity.

> structure things as a loosely coupled set of smaller components

Mind elaborating upon this as well, pretty please?

You'll notice yourself when you try to actually apply this idea in practice. But a possible analogy is: How many tall buildings are around your place, what was their cost, how groundbreaking are they? Chances are, most buildings around you are quite low. Low buildings have a higher overhead in space cost, so especially in denser cities, there is a force to make buildings with more levels.

But after some levels, there are diminishing returns from going even higher, compared to just creating an additional building of the same size. And overhead is increasing. Higher up levels are more costly to construct, and they require a better foundation. We can see that most higher buildings are quite boring: how to construct them is well-understood, there isn't much novelty. There just aren't that many types of buildings that have all these properties: 1) tall/many levels 2) low overall cost of creation and maintenance 3) practical 4) novel.

With software components it's similar. There are a couple of ideas that work well enough such that you can stack them on top of each other (say, CPU code on top of CPUs on top of silicon, userspace I/O on top of filesystems on top of hard drives, TCP sockets on top of network adapters...) which allows you to make things that are well enough understand and robust enough and it's really economical to scale out on top of them.

But also, there isn't much novelty in these abstractions. Don't underestimate the cost in creating a new CPU or a new OS, or new software components, and maintaining them!

When you create your own software abstractions, those just aren't going to be that useful, they are not going to be rock-solid and well tested. They aren't even going to be that stable -- soon a stakeholder might change requirements and you will have to change that component.

So, in software development, it's not like you come up with rock-solid abstractions and combine 5 of those to create something new that solves all your business needs and is understandable and maintainable. The opposite is the case. The general, pre-made things don't quite fit your specific problem. Their intention was not focused to a specific goal. The more of them you combine, the less the solution fits and the less understandable it is and the more junk it contains. Also, combining is not free. You have to add a _lot_ of glue to even make it barely work. The glue itself is a liability.

But OOP, as I take it, is exactly that idea. That you're creating lots of perfect objects with a clear and defined purpose, and a perfect implementation. And you combine them to implement the functional requirements, even though each individual component knows only a small part of them, and is ideally reusable in your next project!

And this idea doesn't work out in practice. When trying to do it that way, we only pretend to abstract, we just pretend to reuse, and in the process we add a lot of unnecessary junk (each object/class has a tendency to be individually perfected and to be extended, often for imaginary requirements). And we add lots of glue and adapters, so the objects can even work together. All this junk makes everything harder and more costly to create.

> structure things as a loosely coupled set of smaller components

Don't build on top of shoddy abstractions. Understand what you _have_ to depend on, and understand the limitations of that. Build as "flat" as possible i.e. don't depend on things you don't understand.

It reminds me of huge enterprise-y tools, which in the long run often are more trouble than they're worth (and reimplementing just the subset you need perhaps would be better), and (the way you speak about OOP) bloated "enterprise" codebases with huge classes and tons of patterns, where I agree making things leaner and less generic would do a lot of good.

At first however I thought that you're against the idea of managing complexity by hierarchically splitting things into components (i.e. basically encapsulation), which is why I asked for clarification, because this idea seems fundamental to me, and seeing that someone is against it got me interested. I think now though that you're not against this idea, and you're against having overly generic abstractions (components? I'm not sure if I'm using the word "abstractions" correctly here) in your stack, because they're harder to understand, which I understand. I assume this is what blackbox means here.

Does it sound correct?

I also think it's about how many people you can get to buy-in on an abstraction. There probably are better ways of doing things than the unix-y way of having an OS, but so much stuff is built with the assumption of a unix-y interface that we just stick with it.

Like why can't I just write a string of text at offset 0x4100000 on my SSD? You could but a file abstraction is a more manageable way of doing it. But there are other manageable ways of doing it right? Why can't I just access my SSD contents like it's one big database? That would work too right? Yeah but we already have the file abstraction.

>But OOP, as I take it, is exactly that idea. That you're creating lots of perfect objects with a clear and defined purpose, and a perfect implementation. And you combine them to implement the functional requirements, even though each individual component knows only a small part of them, and is ideally reusable in your next project!

I think OOP makes sense when you constrain it to a single software component with well defined inputs and outputs. Like I'm sure many GoF-type patterns were used in implementing many STL components in C++. But you don't need to care about what patterns were used to implement anything in <algorithm> or <vector>. you just use these as components to build a larger component. When you don't have well defined components that just plug and play over the same software bus, no matter how good you are in design patterns it's gonna eventually turn into spagetti un-understandable mess.

I'm really liking your writing style by the way, do you have a blog or something?

A database would not work as mostly unstructured storage for uncoordinated processes. Databases are quite opinionated and require global maintenance and control, while filesystems are less obtrusive, they implement the idea of resource multiplexing using a hierarchy of names/paths. The hierarchy lets unrelated processes mostly coexist peacefully, while also allowing cooperation very easily. It's not perfect, it has some semantically awkward corner cases, but if all you need is multiplexing a set of byte-ranges onto a physical disk, then filesystems are a quite minimal and successful abstraction.

Regarding STL containers, I think they're useful and useable after a little bit of practice. They allow you to get something up and running quickly. But they're not without drawbacks and at some point it can definitely be worthwhile to implement custom versions that are more straightforward, more performant (avoiding allocation for example), have better debug performance, have less line noise in their error messages, and so on. The most important containers in the STL are quite easy to implement custom versions with fewer bells and whistles for. Maybe with the exception of map/red-black tree which is not that easy to implement and sometimes the right thing to use.

Thank you! I don't get to hear that often. I have to say I was almost going to delete that above comment because it's too long, the structure and build up is less than clear, there are a lot of "just" words in it and I couldn't edit anymore. I do invest a lot of time trying to write comments that make sense, but have never seen myself as a clear thinker or a good writer. To answer your question, earlier attempts to start a blog didn't go anywhere really... Your comment is encouraging though, so thanks again!

What exactly does that roundtrip latency number measure (especially your 1us)? Does zero copy imply mapping pages between processes? Is there an async kernel component involved (like I would infer from "io_uring") or just two user space processes mapping pages?

The actual (one-way cross-core) latency on modern CPUs varies by quite a lot [0], but a good rule of thumb is 100ns + 0.1ns per byte.

This measures the time for core A to write one or more cache lines to a shared memory region, and core B to read them. The latency is determined by the time it takes for the cache coherence protocol to transfer the cache lines between cores, which shows up as a number of L3 cache misses.

Interestingly, at the hardware level, in-process vs inter-process is irrelevant. What matters is the physical location of the cores which are communicating. This repo has some great visualizations and latency numbers for many different CPUs, as well as a benchmark you can run yourself:

[0] https://github.com/nviennot/core-to-core-latency

Of course a round trip will take more time, but it’s not meaningfully different from two one-way transfers. You can just multiply the numbers I said by two. Generally it’s better to organize a system as a pipeline if you can though, rather than ping ponging cache lines back and forth doing a bunch of RPC.

I'm still not sure that it brings a lot to the table for ordinary application development.

Compare to <iostream>, which is stateful and slow.

There's also std::format which might be safe and flexible and have some of the advantages of printf. But I can't use it at any of the places I'm working since it's C++20. It probably also uses a lot of template and constexpr madness, so I assume it's going to be leading to longer compilation times and hard to debug problems.

I would not use iostreams, but neither would I use printf.

At the very least if you can't use std::format, wrap your printf in a macro that parses the format string using a constexpr function, and verifies it matches the arguments.

So such a strong "at the very least" is misapplied. All this template crap, I've done it before. All but the thinnest template abstraction layers typically end up in the garbage can after trying to use them for anything serious.

I also find it unreadable; beyond the trivial I always need to refer to the manual for the correct format string. In practice I tend to always put a placeholder and let clangd correct me with a fix-it.

Except that often clangd gives up (when inside a template for example), and in a few cases I have even seen GCC fail to correctly check the format string and fail at runtime (don't remember the exact scenario).

Speed is not an issue, any form of formatting and I/O is going to be too slow for the fast path and will be relegated to a background thread anyway.

Debugging and complexity has not ben an issue with std::format so far (our migration from printf based logging has been very smooth). I will concede that I do also worry about the compile time cost.

Mutex is for where you have that ability, and ensures at runtime that accesses get serialized.

This means no atomic operations or syscalls or what have you.

I can see that there are some cases where you have heap-data that is only visible in the current thread, and the borrow checker might be able to see that. But I can imagine that there are at least as many cases where it would only get in the way and probably nudge me towards unnecessary ceremony, including run-time overhead.

    struct Entry {
        msg: Mutex<String>,
    }
    ...
    // Construct a new object on the stack:
    let mut object = Entry { msg: Mutex::new(String::new()) };
    // Exclusive access, so no locking needed here:
    let mutable_msg = object.msg.get_mut();
    format_message(mutable_msg, ...);
    ...
    // Publish the object by moving it somewhere else, possibly on the heap:
    global_data.add_entry(object);
    // From now on, accessing the msg field would require locking the mutex

    let mut object = prepare_generic_entry(general_settings);
    let mutable_msg = object.msg.get_mut();
    do_specific_message_modification(mutable_msg, special_settings);

There may be other situations where you have an object in a specific state that makes it effectively owned by a thread, which might make it possible to forgo locking it. These are all very ad-hoc situations, most of them would surely be very hard to model using the borrow checker, and avoiding a lock would most likely not be worth the hassle anyway.

Not sure how this can help me reduce complexity or improve performance of my software.

Are you sure? Isn't having data be local to a thread the most common situation, with data sharing being the exception?

>Or, the data is linked globally in a data structure and the only way to access it safely is by knowing exactly what you're doing and what the other threads are doing.

That's exactly what the borrow checker does. It tracks how many mutable references you have to your data structure at compile time. This means you can be sure what is local and what is shared.

Meanwhile without the borrow checker you always have to assume there is a remote probability that your mental model is wrong and that everything goes wrong anyways. That's mentally exhausting. If something goes wrong, it is better to only have to check the places where you know things can go wrong, rather than the entire code base.

I keep very little state on the stack -- mostly implicit stuff like mutex lock / mutex unlock. By "state" I mean object type things that get mutated or that need cleanup. I always have a "database schema" of my global state in mind. I define lots of explicit struct types instead of hiding state as locals in functions. I've found this approach of minimizing local state to be the right pattern because it enables composability. I'm now free to factor functionality into separate functions. I can much more freely change and improve control flow. With this approach it's quite rare that I produce bugs while refactoring.

So yes, I have lots of locals but I share basically none of them with other threads. Also, I avoid writing any code that blocks on other threads (other than maybe locking a mutex), so there's another reason why I would not intentionally share a local with another thread. Anything that will be shared with another thread should be allocated on the heap just for the reason that we want to avoid blocking on other threads.

In that sense, the borrow checker is a tool that would allow me to write code more easily that I never wanted written in the first place.

You want the object to present its valid operations, but the object could also be constructed in single or multithreaded situations.

So you'd offer two APIs; one which requires a shared reference, and internally locks, and a second which requires a mutable reference, but does no locking.

Internally the shared reference API would just lock the required mutexes, then forward to the mutable reference API.