I have an Actor framework which uses a vanilla std::deque for method pointers, and to add messages to the queue, the locking technique is a Benaphore (the original Futex, which uses an atomic and a locking primitive, with the twist that my locking primitive is a combo of spinlock/mutex based on retry count). Nothing special. Benchmarks show that very rarely does the message push function block, and the chance of an O…
With a post like this, however interesting, you really should link the code. Not only will it prove your claim, but others like me will find the idea intriguing and immediately want to see how it's done.
Peredvizhnikov Engine: Lock-free game engine written in C++20
41–50 of 183 posts
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#42It’s quite the stretch to call this a game engine, rather than a tech demo for clever locking strategies.
Say you are in the middle of building a house. The foundation has been built and they are framing it up.
Is it a house?
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#43Earlier quoted context omitted.
[flagged]
The Russian word can be broken into three sections. The first part is a prefix associated with a transition. The middle means movement and the bit at the end means a person that does that. So even though the group of artists with that name were translated as "the wanderers" or "the itinerants", the word literally means people who move around.
That's an awesome wordplay with the intent of the engine
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#44I have an Actor framework which uses a vanilla std::deque for method pointers, and to add messages to the queue, the locking technique is a Benaphore (the original Futex, which uses an atomic and a locking primitive, with the twist that my locking primitive is a combo of spinlock/mutex based on retry count). Nothing special. Benchmarks show that very rarely does the message push function block, and the chance of an O…
My benchmarks show that the price is acceptable Well, except to people who have a hard requirement that there never be this unpredictable, infrequent longer delay you mention.
It's probably fair to claim that zero* game developers have this hard requirement. At best they have a strong desire which might be partially backed up by benchmarks and squinting hard enough.
*: ignoring deliberately esoteric cases, like Doom on a hard real-time system.
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#45It’s quite the stretch to call this a game engine, rather than a tech demo for clever locking strategies.
I wouldn't even call it clever. The Actor model trivializes avoiding locks, since you're letting everything act on stale information (if the actors process concurrently) and then just iterating through their intended actions against a singleton state and resolving those conflicts with sequential code.
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#46Earlier quoted context omitted.
[flagged]
> Unless the name is explained somewhere, I'm convinced it's complicated on purpose. Tell me you only speak English without telling me you only speak English.
I guess that my pun using "unreal" in a post about a game engine went under the radar and now I look like I can only speak English which is kinda flattering and worrying.
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#47> At the moment, the only supported platform is Linux.
Regardless of your feelings on the status quo, there is one thing you must do when building a game engine if you want it to succeed: support Windows.
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#48[flagged]
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#49Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#50Does anyone have experience debugging/profiling highly contended critical sections of STM vs a more traditional mutex implementation? At the end of the day something has to mediate concurrent access to shared memory, there’s no free lunches, and mutexes are so well optimized, profiled, and understood. I’m unclear if the same applies to STM where a transaction may need to be retried an unbounded(?!) number of times.
Yes. The mediator in this case is the scheduler. The one that actually calls the asynchronous block. Potentially retrying it if it fails. In the OP’s code, there’s atomic blocks, sequential execution of blocks, stateful blocks, etc for ensuring singular access at a time. The meat here is scheduler.cpp. It uses std::coroutines. This is like async/await in other languages. The scheduler has a queue of work(coroutines)…
Thanks!
So the scheduler serializes execution of critical sections?
> In this case, messages are passed between work that contains the data. No locks are required at the expense of memory footprint.
Are messages copied or moved? If moved is there compile time checking for ownership or runtime debugging tools?