Map concurrent iteration and writes

[violet island]

Purpose: Multiplayer real time .io-style game
Issue: I run a game's update loop and each player's socket update loop in own goroutines. This makes things nice and neat for me. But the main game loop each tick reads and writes to the maps for entities. So does the socket update loop (reads only). I want to lock the maps during each goroutine so that it does not cause the concurrent map iteration and map write error. I tried stuff like this image in the socket update loop, and the second image for the game loop. Error persists. Any idea how to properly use the mutex locks for my situation?

[violet island]

I think I solved the problem by adding more locks, and repositioning unlock to be after the loop

but I'm leavinthis open if someone else has any feedback

[kindred smelt]

should use Lock instead RLock if your game loop need to write something.

should really careful the lock that you share game and socket, it is easily to make deadlock

[quiet mist]

You said you're using maps--have you tried using sync.Map?

it's built for exactly this sort of thing, manages concurrent read locks and write locks for you, you just have to cast things on the way out

Otherwise, make sure you release locks as soon as they're not needed so you avoid lock collision issues. Would strongly suggest simplifying control flow and not using defer for these.

[lusty ember]

something i noticed:
defer is only ran AFTER the function returns
in this case, your player lock will be locked for the entirety of the function call even after mobs lock is called
if the function is lengthy, you should split parts which uses mutex into smaller segments

[violet island]

I haven't

I think that's a good idea

[violet island]

I had actually implemented that like this

[violet island]

Upon research it seems slower and a more complex api

[violet island]

I'll try this

maybe it'll fix it

lemme try to spawn a shitton of entities rq

Lmao I love go. Going from JS -> Go, I can support hundreds of players and hundreds of thousands of entities more than the JS version

[lusty ember]

what is g.MobsLock protecting?

is it protecting w.Mobs?
you are for each on mob but you are not altering mob

if you are not altering w.Mobs you dont need to lock
you could just Rlock

RLock means you are trying to acquire a READ ONLY lock

this is neat because multiple read locks can be acquired at once, without blocking each other

of course if you dont anticipate parrallel reads you might be fine using a Mutex instead of RWMutex, as it's not entirely free in terms of performance

[violet island]

hmm