Which one is better to use Builtin map with mutex lock or sync.Map in a case where i want to lock value of specific key instead of locking whole map?

Getting Help
1

I am using map[float64][]custom_data. my use case is that values for a key must be added or deleted by only one go routine and if value([] custom data) of key is being used by one go routine then other should wait for its operation’s completion.
as far as i know sync.map locks whole map but i don’t want to lock whole map instead i want to lock value or array of custom data of a particular key which one should i use builtin map or sync.map?

2

Well, i guess you can’t with standard sync library. Mutex mechanism don’t lock your variable in a particulary way but ensure that only one goroutine access your variable.
If you still want that you coud implement other dynamic structure to replace the map based on semaphores where each struct have his own flag and every rw operation coud check that flag.

1 Like
3

You know better what you intend to use your map for than we do as far as what decision you should ultimately make about how you implement concurrency safety with your map.

However, here is an article that elucidates the many options you have: https://medium.com/@deckarep/the-new-kid-in-town-gos-sync-map-de24a6bf7c2c

I would wonder what you are trying to accomplish though, because you might find concurrency isn’t even required for your work especially if only one go routine at a time could access it anyway. However, sync.Map seems to do precisely what I gather you want.

1 Like
4

values for a key must be added or deleted by only one go routine

says the reader/modifier goroutines are tied to the key.
But

if value( custom data) of key is being used by one go routine then other should wait for its operation’s completion.

suggests that they’re not tied, you just want to avoid data race of concurrent access.

Use a sync.RWMutex for the map access first.
If performance is not good enough, then you can shard your map to submaps with each having its own lock.

It depends on your use case, but maybe the “managing goroutine per key, commands (get/set/modify) on channel” pattern could work, too.

2 Likes
5

thanks foa
i used a struct with rw lock as values of map keys its working fine but sometime it behaves strangely and throws error map read write failed which scares me

6

thanks foa
concurrency is required because values of a key can be manipulated at same time by two or more go routine so i want to lock values to avoid disordered manipulation
i am just looking sync.map lock entire map or values of a key ?

7

thanks foa
with sync.rwmutex its working fine but at some time it throws error of map read and write failed

8

I often use this kind of simple locking

var m = &sync.Mutex{} // even as global var

// somewhere in the code
m.Lock()
some_name[key_name] = some_value
m.Unlock()

So, accesing in that way is safe (at least i didn’t have problems with). Of course you coud use read or write blocking too. If you have errors (panics?) be sure that is from sync cause and not from other related causes.

About performance, basically things happen quickly even on large maps. The only problem coud apear when too large maps is not updated in time or you can’t read it in time because of too many locks but this are large scale cases that can be handled in other specific ways, i guess not with maps.

9

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.