Hi Eric here is some sample code, with - a "correct" implementation <https://play.golang.org/p/tLjXXcHq5H> : it passes the race detector, and it behaves as expected : no overlapping of queries on a specific file. - an "incorrect" impl <https://play.golang.org/p/TDpLJAfXm6> that doesn't guard the map : it would seem like it works, but the race detector immediately reports the fraud.
The only subtle thing is to not confuse the mutex for the map, and the mutex for each file. There should not exist a "function that handles the unlocking of the map[string]*sync.Mutex", the map access itself is ultra-fast and the map locking should be nothing more than mutex.Lock() ; defer mutex.Unlock() . It is important to release the global mutex *before* executing the sqlite query. For the general problem of re-acquiring a mutex, I learned today in the archives that code involving recursive (reentrant) mutex locking is frowned upon, regarded as a code smell, a bad practice that is very bug-prone. Cheers Val On Thursday, December 29, 2016 at 7:43:19 PM UTC+1, Eric Brown wrote: > > Thanks Val, I actually tried that approach... and failed. Perhaps I > incorporated it wrong. I put the handling of locking/unlocking of the > map[string]*sync.Mutex in it's own function, which was encapsulated in the > global mutex like you suggested. Only problem was, was that the database > function ran once... because when it went to call the function that handled > the unlocking of the map[string]*sync.Mutex, it was already locked by a > previous goroutine trying to lock the map[string]*sync.Mutex. > > Hahaha... I hope I made sense. My brain is hurting here. It doesn't help > that I'm fairly new to this type of stuff in Go. Appreciate you > assistance, however. Thank you! > > > > On Thursday, December 29, 2016 at 1:28:34 AM UTC-6, Val wrote: >> >> Hello Eric >> You may use a map[string]*sync.Mutex where key is the DB filepath, and >> protect that map with a global mutex. >> >> Note that a mutex value must not be copied, often it is necessary to use >> pointers. >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
