Concurrency on keys in a sync map

Trying to use a sync map in golang to provide ability to acquire a lock on a particular string(say "LOCK1").

package main

import (
	"fmt"
	"sync"
	"time"
)

var lockMap sync.Map
func main(){

	counter := func(key string,routineId string) {
		_,ok := lockMap.Load(key)
		if(ok){
			fmt.Println(key+ " skipped by "+ routineId)
			return}

        lockMap.Store(key,true)
		defer lockMap.Delete(key)
		for i := 0; i < 10; i++ {
			fmt.Println(key+ " locked by "+ routineId)
		}
	}

	// Starting some goroutines
	go counter("LOCK1","routine1")
	go counter("LOCK1","routine2")
	go counter("LOCK1","routine3")
	go counter("LOCK1","routine4")
	go counter("LOCK1","routine5")
	//adding some sleep so the  routines can execute for sometime
	time.Sleep(time.Second)
}

I am aware that sync map uses a RWMutex under the hood.
But, I am trying to understand if sync map allows multiple writes on different keys at the same time or only a single routine can do a write on the entire map at one time?

So let's say the key "LOCK1" is being set by routine1, would routine2 be able to set a new value "LOCK2" concurrently or does it have to wait for the first write to finish.

For each key, you want to access the existing lock, or create a new lock if there isn't one. With sync.Map.LoadOrStore you can do this atomically.

// Pre-allocate a new lock, in case it's needed for this key.
newLockIfNeeded = new(sync.Mutex)
lock, _ = lockMap.LoadOrStore(key, newLockIfNeeded)
// Safely acquired the (potentially new) lock for the key
lock.Lock()
defer lock.Unlock()
// do work ...

I'll try to provide a direct answer to OP

> sync map allow multiple writes on different keys at the same time?

Yes, but under specific conditions

sync.Map is optimized for unique writes with many readers. It is slow for having many routines update the same key (see sync.Map use cases). Internally it contains a read map, a dirty map, and atomic read/writes to pointers. Some operations use a mutex, while others bypass it for speed.

Yes, simultaneous writes/deletes are allowed only if

• The key already existed (m.read.Load())
  • atomic.LoadPointer gets the fast read map, but callers can still arrive at the next step together
• The above key wasn't or isn't being updated/deleted
  • Wasn't updated: sync.Map checks the expunged pointer to see if it was updated elsewhere
  • Isn't being updated: key was not changed while checking if it was expunged (CompareAndSwapPointer)

Yes, simultaneous reads are allowed if either

• The key does not exist while no new keys were added
• The key exists and is not being updated (like above)

No, a mutex lock is used when

• Storing a new key
  • Example: bulk adding distinct keys is slow
• Loading a missing key after a new key was added
  • Example: frequent deleting and checking for deleted is slow
• Reading or writing a key that is being updated
  • Example: many updating the same key is slow

However, the mutex does not block the Yes cases

I ended up using a sync map of key -> mutex. Thanks for the pointers Hymns for Disco. For reference here is the working impl:

package main

import (
	"fmt"
	"sync"
	"time"
)

//var lockMap sync.Map
var lockMap2 sync.Map
func main(){

	//lockMap2 := make(map[string]*sync.Mutex)
	counter := func(key string,routineId string) {
		mutex,_ := lockMap2.LoadOrStore(key,&sync.Mutex{})
		mutex.(*sync.Mutex).Lock()
		defer mutex.(*sync.Mutex).Unlock()
		for i := 0; i < 100; i++ {
			fmt.Println(key+ " locked by "+ routineId)
		}
	}

	// Starting some goroutines
	go counter("LOCK1","routine1")
	go counter("LOCK1","routine2")
	go counter("LOCK1","routine3")
	go counter("LOCK1","routine4")
	go counter("LOCK1","routine5")
	//adding some sleep so the  routines can execute for sometime
	time.Sleep(time.Second)
}