Welcome to the Builder Academy

Question Multithreading

31 Mar 2023 20:01 #10295 by doogie
Multithreading was created by doogie
I added a second thread to tbaMUD (pthreads) that basically separates the heatbeat functions from the lower level IO functions. It was fairly easy to do in stock tbaMUD as a test, but even though it works like a champ, it is not actually thread safe. I haven't experienced any side effects of not protecting it despite running it through the ringer with a series of triggers on a few clients, but I know underneath bad things could happen with the wrong combination of inputs.

I started lacing in protections but I wanted to ask what efforts have been made on this front and what, if any, interest exists in a multithreaded version of tbaMUD? I am personally working on personality traits (a la Dwarf Fortress) that could eventualy necessitate multiple threads, but don't know what the wider interest is in multithreaded ops.  Anyone hitting single thread limitations/experiencing code-related/unexplained lag?


Please Log in or Create an account to join the conversation.

01 Apr 2023 13:10 #10297 by thomas
Replied by thomas on topic Multithreading
Interesting :)

There has, to my knowledge, not been done any work on running multiple threads in neither Circlemud or TBA. I don't think it's really been a bottleneck for most people.

I'll be interested to see what you come up with.

Please Log in or Create an account to join the conversation.

17 Apr 2023 19:47 - 17 Apr 2023 19:50 #10314 by doogie
Replied by doogie on topic Multithreading
Yeah, I'm not sure it is necessary either, but I was mostly curious to see what it would take to get it to work and if it might help ward off the spurious lag monster. The jury is out on both, but if you want to take a look at the approach, I created a fork here: github.com/mnocu/tbamud which should work (dubiously) in Linux. I'll also look for a spot to attach the 5 files I modified somewhere here.

The basic idea was to launch a facsimile of the game loop in another thread that handles heartbeat functions and leave the I/O in the original thread. So, the bulk of the changes are in comm.c with a few additions to comm.h, structs.h, and the function/macros to handle the mutex locks in utils.c and utils.h. That's really all I've done to get a working multithreaded copy of tbamud.

Mutex locks are missing in a lot of places -- I didn't do a full analaysis of where they will be required, but there are a lot of places where they are still needed to guard the descriptors. Ideally, the descriptor is the where the threads intersect... In thread 1, the game_loop() should handle the low-level descriptor functions (and perhaps anything that might need to happen in the background) while thread 2 runs the bulk of the game mechanics (which inherently will need to access the descriptors at times). An analogy would be thread one is the joystick, keyboard, and monitor I/O and thread two is all the underlying mechanics of the game.

If nothing else, it's an interesting experiment in dualing threads and maybe a starting point (or example of what not to do) for anyone else thinking about recruiting additional cores to their cause.
Last edit: 17 Apr 2023 19:50 by doogie.

Please Log in or Create an account to join the conversation.

Time to create page: 0.237 seconds