https://github.com/orcaman/concurrent-map/blob/master/concurrent_map.go#L17 no way, they embedded a mutex, what the...
I always embed mutex in my needed structs, is that a bad practice?
what’s the reason to expose Lock() and Unlock() to your API?!
oh, no I don't expose it. but I embed mutex like: type JoeBidenIsNotPresident { sync.Mutex val int } func(JBINP ...) Add() { JBINP.Lock() JBINP.val++ JBINP.Unlock() } ohhh, I guess this exposes mutex as well?
you do expose it, that’s what embedding does
also, use defer Unlock(), there’s no more additional runtime cost for those kinds of defers since 1.14
I've just read an old article
What about sync.Map? What’s missing there for you?
https://golang.org/pkg/sync/#Map
I don't know lol, actually I haven't really studied all aspects of mutexes. Let me see that
just use sync.Map if you don’t know why you’d need something else
I'm using it to control conversations so functions in the app don't call db independently and use an interface to interact with conversations table
I don’t understand 🙂
Conversation table in db has a few fields like last_message_Id. If 2 users in a conversation call that record at the same time and increment last_message_id, then both might get same message ids.
you’re supposed to use transactions for these kinds of problems
I'm not sure if transactions would help here. last_message_id = 0 User A sends a new message to User B User B sends a new message to User A Both at the same time, now the updates handler goroutine fetch last_message_id for each request, both will fetch 0 in this case. So if they try to update the value, it will be 1 instead of 2. I thought transactions is only when you want to write data
that’s exactly what transactions were made for
> I thought transactions is only when you want to write data no.
You saved me once again, thank you
u r welcome
Обсуждают сегодня