Up to Main Index Up to Journal for July, 2018 JOURNAL FOR SUNDAY 29TH JULY, 2018 ______________________________________________________________________________ SUBJECT: A thought on scheduling DATE: Sun 29 Jul 22:53:41 BST 2018 The hot summer continues. Temperatures in my study have been over 30°C this week. Tried killing one of my Raspberry Pi (model B). The Pi was sat on top of a network switch and both became rather hot. I didn’t notice until the Pi stopped responding on the network. Once the Pi had been moved and left to cool for a bit it rebooted just fine and started working normally again. This week I have stopped fiddling around with Raspberry Pi[1] and returned to working on WolfMUD properly. I’ve mostly been concentrating on the writing of recordjar files — coding tests and making some minor improvements to the code in the recordjar package. Previously, when I was load testing the Pi Zero, I noticed that scheduling of goroutines was very unfair (random) under heavy load. This caused pauses when processing commands, and you would start to see things like: >sneeze You see Diddymus enter. > You see Diddymus go north. > You sneeze. Aaahhhccchhhooo! > In this example you type the command ‘sneeze’ and press enter. While you are waiting for the sneeze to acquire the necessary location locks Diddymus enters and then leaves again. Entering and leaving are two separate commands to your one. This can arise due to goroutine scheduling being random. Both yourself and Diddymus need location locks. Diddymus gets the locks first and enters, the locks are then released. Due to other players on the server someone else then gets the location locks while yourself and Diddymus are waiting. Again Diddymus then gets the location locks before you and leaves. Finally, you get the location locks and sneeze. I don’t want to globally serialise access to locations. Otherwise a player wanting locks for one location would end up waiting on a player in an independent location. On multicore machines, where we can handle multiple players at once, performance would suffer. Serialising locks per location would require add a channel to every location, and each channel would have to have a capacity equal to the maximum number of players allowed on the server. The channels need to be that large, otherwise players would block writing to the channel and which player gets unblock is again random — leaving us back at square one. I could allocate the channels from a pool as and required, but I think that could get overly complicated quickly. The answer may be a hybrid of what we have now and queuing. Instead of using a mutex for location locking we switch to channels. The advantage of using a channel is that we can use a switch statement to try and get a lock and do something else if the lock is not immediately available. The something else would be to release any locks we have acquired and then queue. Queued players are then allowed to acquire locks one after the other in FIFO order. This could also get overly complicated quickly. For now I’m just mulling over ideas, and making a few notes for later. I don’t want to get distracted from writing those pesky, but essential, tests. -- Diddymus [1] The Raspberry Pi are now setup "just right" for how I like to work. Up to Main Index Up to Journal for July, 2018