weilawei

People are people are people.

Public Key

npub1hygs455y8xt0a3hcqh5k4d8gdg7xvveuplj994qnzywfl8pg5ycspl98h0

NIP-05 Address

weilawei_at_mastodon.online@momostr.pink

Profile Code

nprofile1qqstjyg262zrn9h7cmuqt6t2kn5x50rxxv7qlezj6sf3z8ylns52zvgpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dshdv5st

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1hygs455y8xt0a3hcqh5k4d8gdg7xvveuplj994qnzywfl8pg5ycspl98h0

Show more details

Last Notes

2024-06-08 10:07:04

- reply

For instance, the interface of a queue is front()/back()/push()/pop(), but there's no obvious way to make that truly atomic without locking. It also requires that front() and back() have non-const variations, which means now I have to hand back a reference to something that -logically- cannot be modified or it breaks the invariants for the lock-free code.
I think most performance concerns are overblown if you're skimming the generated code, which is normal for high-perf code.

2024-06-08 10:00:36

- reply

I have thoughts on the STL, but they're related to concurrency, not game dev. Frankly, the STL is specced with a single-threaded model of execution in mind, and it makes this explicit by requiring certain behaviors out of containers.
Turns out, this is an issue trying to map that interface onto lock-free implementations, because it assumes mutability--and lock-free structures don't work that way.
I have unordered_map, unordered_set; I'm working on queue & vector.