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