Up to Main Index Up to Journal for October, 2015
JOURNAL FOR SATURDAY 31ST OCTOBER, 2015
______________________________________________________________________________
SUBJECT: Happy Halloween! Locking, IDs & minor dev branch update
DATE: Sat 31 Oct 18:09:58 GMT 2015
This week I've been working on adding the networking code back into WolfMUD.
In order to do that a few other pieces of the puzzle have to be sorted out.
The first of these is locking. Locking is very important to coordinate between
multiple Go routines all accessing the world and it's content at the same
time. Otherwise strange things like two players picking up the same item at
the same time could happen - with both players having the same reference to
the same item. Or you could fight and kill something only to have it kill you
just after it dies. Prototypes 1,2 and 3 had the 'Big Room Lock' or BRL.
The idea of the BRL was simple. In order to do anything you lock the location
where you are, do something and release the lock. If you wanted to do
something that involved multiple locations you locked all of the locations you
were going to use. So to move from A to B you lock A and B, remove yourself
from A and add yourself to B, release locks on B then A.
The BRL is a very course locking mechanism as opposed to the very, very finely
grained locking in the Java version. As mentioned above the BRL works at the
location level. The Java version worked at the item level. As a result, in the
Java version, everything had to be synchronised and any code changes had be
thought through very carefully. The advantage of the Java version was that
different things could happen at the same time in the same location.
So it's a trade off. The BRL sacrifices complexity for simplicity with the
consequence that, within a location, things always happen one at a time. Is
this a big sacrifice? No. Players will not even realise it. The only time it
could possibly be an issue would be if thousands and thousands of things were
to happen in one location at the same time - even then all the player's would
notice is a slight delay. The benefits are that programmers will hardly have
to think about locking at all. For the most common case of something happening
in a single location - get or drop an item, read or examine something, etc. -
locking will be handled automatically. For cases involving multiple locations
- moving from A to B, throwing or firing an item from A to B, teleporting from
A to B, etc. - there will be a few extra lines of code. Even for the multiple
location instances it may be possible to handle it automatically as well.
The only question now is should the BRL 'Big Room Lock' be renamed? WolfMUD
does not really have rooms or locations. For flexibility anything with an
Inventory can be treated as a room or location. So it will be the Inventory
that will be effectively locked. So should we have a BIL 'Big Inventory Lock'?
For now I'll keep referring to it as BRL - it sounds nicer and I think it
conveys it's purpose well.
The next piece of the puzzle is unique IDs. Each Inventory needs to have a
unique ID associated with it. This is so that inventories can be consistently
locked in the same order - lowest ID to highest ID. This is how we prevent
dead locks and live locks. This is the classic resource hierarchy solution
proposed by Dijkstra[1] to the (again classic) dining philosophers problem[2].
In our case the forks are our inventories.
As a side note the Java version used the memory address of objects as the
unique ID. In Go I believe the garbage collector will, at some point, be able
to relocate things in memory so the Java technique can't be used for the Go
version. I'm not even sure if this still holds for later versions of Java.
So that's what I have been working on currently. I've also pushed a very small
update to the public dev branch which adds a 'VERSION' command to help people
when reporting bugs.
Time to get out the pumpkin again!
__
///
/ __ __ \
\/ __ \/
_ \/ _
\\/\/\//
\ \/\/\/ /
HAPPY HALLOWEEN
--
Diddymus
[1] Edsger W. Dijkstra: https://en.wikipedia.org/wiki/Edsger_W._Dijkstra
[2] The dining philosophers problem:
https://en.wikipedia.org/wiki/Dining_philosophers_problem
Up to Main Index Up to Journal for October, 2015