ID:2075484
 
Applies to:Dream Daemon
Status: Open

Issue hasn't been assigned a status value.
So I got to thinking about map threads.

On /tg/station13's servers, map sending makes up a decent chunk of the cpu usage per tick, like 35% at peak times during lots of things happening.

What if we could make map threading (using multiple threads to send out client updates during each tick) work?

Now! hear me out, it won't work in the form of the original idea, where map threads ran 100% separately from the main game tick (or seemed to, maybe I'm wrong on this point.).

But! what if it still ran with the game tick? where we can stop things happening while map's are sending out?

This runs on a basic assumption, that nothing in the per-client part of map sending needs to actually write to any shared memory.

Basically, if you make sendmaps() start all the client threads, and have it wait until all threads are finished before returning, you can let them share access to the world state, as the only thing that can happen, in any thread during that time frame, is reads. It's thread safe if you know (by blocking the main thread) that nothing being shared can change.

No costly locks, no thread contention, it's still mostly linear, we just use the other threads for processing each's client's interesting turfs list.

Because ya, async threading just isn't gonna work, but a blocking worker thread model will work. Once you have the boilerplate code for starting worker thread and blocking until they all finish, you could then add that to other costly things, like view(), anything costly where you can figure out an easy way to partition the workload, could be threaded. client interested turfs is an easy target, you partition the workload to each client, and you can potentially have pre-made threads ready for each client to lower on overhead of creating the threads. (Or you partition the workload by splitting up the client array by the number processors. But this has issues where one worker thread could get all the expensive clients to process, best to just do one static thread for each client)

I don't know, what do you think lummox? I know on a managed language platform, this would be insanely easy, but on c++, i'd think the hard part would be the boilerplate code to manage the threads, but it wouldn't be impossible. Is there something i'm missing that makes this harder to do then i'm thinking?
This is what the map threading mode did already. There actually is some writing to shared memory, but supposedly I had worked around it--although regular threading had to be enabled too, and it just didn't work. Now with the map chunk setup I'm not sure if there are any new wrinkles.

Maybe this could be reenabled if the main thread did some maps and the spinoff threads did their own. Seems iffy, though.
I'd need much more info on the flow and process of sendmaps() then to understand and think up workarounds to issues, but i doubt i'd offer anything you don't already.

also, i take it threading is flatout disabled now, as i tried enabling it and that didn't seem to do anything.
Yeah, threading got disabled fully in the 507 stable release.