Up to Main Index Up to Journal for December, 2019 JOURNAL FOR SATURDAY 7TH DECEMBER, 2019 ______________________________________________________________________________ SUBJECT: Meddling with the status quo DATE: Sat 7 Dec 12:35:09 GMT 2019 December already, nearly the end of 2019. It was 35 years ago I started the very first WolfMUD back on the BBC Micro I absolutely loved. Turn the BBC micro on, two brief beeps and within seconds you get a prompt and can do something. Mainly I programmed in BBC Basic but also some assembler *sigh* :) So what have I been working on? The new finders seem to be working well, and have been received better than I expected. I’ve now moved on to cautiously poking the code dealing with locking. Locking is complicated — and it took a while to get everything just right without causing data races. Since then I’ve left the locking alone and it’s just worked fine. But now I feel it’s time to meddle with the status quo… To start with I’ve removed the sync.RWMutex that the Locate attribute, and hence each instance, had. The Locate attribute now uses the sync.RWMutex from the base Attribute it embeds. I’ve also added a new Attribute.free method. This has the same effect as calling the Attribute.Free method — but it does not take the lock. This is useful in instances such as Locate.Free which acquired the lock, then released it just to call Attribute.Free which immediately acquired the lock again. Overall nothing drastic yet, just cautious poking of the code and a few small tweaks here and there. A minor oversight has been fixed in the frontend.game.init method where the starting Inventory was being locked without calling Inventory.Outermost first. Currently this is a technically correct fix without implications — seeing as we can’t have locations within locations or spawn players inside containers. Changes for this fix and the locking updates are now on the public dev branch. I’ve been running a server under the race detector for days without issue. The changes should be okay, but if you have issues please drop me a quick email and let me know: diddymus@wolfmud.org Next I’m taking a critical look at the base Attribute — which all other attributes embed. My thinking is that a Thing only really needs a single Attribute and that all of the current attributes could actually embed a *Attribute to a per Thing instance, instead of having their own Attribute. This would reduce the number of Attribute instances created and hence the number of sync.RWMutex created. In fact each Thing has its own sync.RWMutex as well. I wonder if it’s possible for Thing and Attribute to share the one mutex? Hrm… time for some more experiments! -- Diddymus Up to Main Index Up to Journal for December, 2019