2016. szeptember 13., kedd 4:01:24 UTC+2 időpontban davidmi...@gmail.com a következőt írta: > > My response is inline..... > > On Monday, September 12, 2016 at 4:13:10 PM UTC-4, Tamás Gulácsi wrote: >> >> TL;DR >> I know what concurrency is. >> > > ok, but I wasn't explaining concurrency to you. > > If you're referring to the paragraph about the cars, I was explaining why > your answer was incorrect. I was not explaining concurrency. > > That's what TL;DR meant: Too Long, Didn't Read.
I feel you fight against locking (synchronizing concurrent access) 'cause you feel that will block all your goroutines. But that's not the case! As Justin said, a lock serializes access only to the the lock, and if you use it properly, it will block only the other (1) goroutine - the others will be able to do what they're doing. A concurrent map is possible to program, but that'd be slower than a non-concurrent-access-safe map with proper synchronization. E.g. if you first populate (write) the map, then read it (and won't modify after), then you won't need locking at all! (Sorry, but for multidimensional array, I associated to the "PHP hammer": https://blog.codinghorror.com/the-php-singularity/) > If you're referring to my comments about the map (following my "Please > clarify....." statement), I was simply setting up the scenario I was facing > and was asking for clarification as to where I may have made a mistake. I > was, again, not explaining concurrency to you. > > >> For a map access, if you hold the lock for as few instructions as >> possible, it shouldn't hurt much. >> > > You either didn't understand the paragraph about the cars or you didn't > read it. Much of what I wrote was explaining why this isn't necessarily the > case. In my case, running goroutines to avoid users blocking each other and > then setting up a bottleneck undermines the point in using goroutines > because they all have to wait for each other anyway to complete their > goroutines. > > >> If you're after an idea of the best solution, that will be harser - maybe >> not a map is the best answer for your specific use case, but a slice. Or a >> slice of maps with hashed access. >> Or just copy the map before read it, and swap the whole map after a >> change. > > > I'm not sure I understand your suggestions here. As far as I know, the > only structure in golang that allows one to use a string as a key would be > a map. > > >> If you can write down the access to the innermost element of your >> multidimensional map as m[a][b][c][d], then you know that you won't have >> more than four levels, so you can use a map[[4]string]string. >> > > I spent about an hour or two trying to get this suggestion to work. I > clearly don't properly understand what you're suggesting. > > >> If you want an unbounded level, then first please define the equality on >> them, to be able to use them as map keys! >> > > I don't understand what you mean by "define the equality" on them. I was > under the impression that Golang has strictly defined equality. > -- 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.
