My response is inline..... On Monday, September 12, 2016 at 7:43:12 PM UTC-4, Keith Randall wrote: > > Tamás's suggestion of using [4]string as the key is a good one. You could > use any struct you want as well, if you want to name the parts of the key. >
I tried that. I can't seem to get it to work. I'm clearly doing something wrong, probably because I am misunderstanding Tamás's response. Test_Map := make(map[[4]string]string) I've tried this way..... Test_Map["Folder_1"]["Folder_2"]["Folder_3"]["Folder_4"] = "File_Name_1" I've also tried this way..... Test_Map["Folder"[0]] = "File_Name_1" Test_Map["Folder"[1]] = "File_Name_2" Test_Map["Folder"[2]] = "File_Name_3" Test_Map["Folder"[3]] = "File_Name_4" The second way isn't really what I'm looking for anyway. I'm trying to get the first way to work. For the first way, I get the following errors..... cannot use "Folder_1" (type string) as type [4]string in map index non-integer string index "Folder_2" invalid operation: Test_Map["Folder_1"]["Folder_2"]["Folder_3"] (type byte does not support indexing) For the second way, I get the following errors..... cannot use "Folder"[0] (type byte) as type [4]string in map index cannot use "Folder"[1] (type byte) as type [4]string in map index cannot use "Folder"[2] (type byte) as type [4]string in map index cannot use "Folder"[3] (type byte) as type [4]string in map index How are you using the map? If you're only reading the map, then concurrent > access is allowed. Concurrent access is only forbidden if one of the > accesses is a write. If you have only occasional writes, a sync.RWMutex > might be appropriate. > As I said, use of a multidimensional map isn't a "one time only" thing and it could appear in numerous circumstances. Some of them may be read only, while others would include plenty of writing. > Yes, locking around the map accesses does serialize the goroutines. > Thank you for understanding my underlying question and answering it. The question is, therefore, how one gets around this problem. (See my further comments on this, below.) > But the shorter the critical section, the faster your app will run. In > your traffic analogy, the more cars/sec can fit though a merge point, the > more traffic flows. And if other parts of the road have a lower speed > limit, it may still pay to make those sections of road wider (parallel). > I made that point in my previous email..... *"That's not to say that there aren't other potential bottlenecks being evaded by using concurrent routines that do no have the shared map problem....."* *The problem I'm having is that the map manipulation would be among the core functionality of the concurrent procedures. Essentially, the cars are on a very short road and do (almost) nothing except go through a merge.* *The answer I'm seeking now is whether or not I can avoid the locking problem by declaring the map within the goroutine so that multiple, independent, instances will be declared. I'm wondering if those would be safe within the context (and only within the context) of each of those goroutines or whether golang will be using the same shared space for each instance, causing problematic behavior.* *In other words, are map instances protected by their scope?* > On Monday, September 12, 2016 at 1:13:10 PM UTC-7, Tamás Gulácsi wrote: >> >> TL;DR >> I know what concurrency is. >> For a map access, if you hold the lock for as few instructions as >> possible, it shouldn't hurt much. >> 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. >> >> >> 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. >> >> If you want an unbounded level, then first please define the equality on >> them, to be able to use them as map keys! >> >> -- 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.
