Re: [go-nuts] Re: concurrent write-only to map ok?
Good point, simple examples are almost never enough. I guess I was hoping that we'd end up with 3-5 examples of a really simple case. Maybe I'll come up with a more complex example. I'm loading under ~5K files in parallel and possibly making an HTTP request for each. I like the slice solution, but I need the files to be accessible later by path (hence the map key). This is a command line utility. Adding parallelism already cut the time down from 1-2 minutes to 5 seconds, so I'm not concerned about map contention. So, my example does kinda capture the core algorithm, but it doesn't explain it very well. On Monday, October 16, 2017 at 9:42:18 AM UTC-7, Bryan Mills wrote: > > On Sunday, October 15, 2017 at 1:45:06 PM UTC-4, Alex Buchanan wrote: >> >> Show me the code! :) >> >> Here's mine: https://play.golang.org/p/ZwAlu5VuYr >> > > The problem that sync.Map is intended to address is cache contention. > Unfortunately, it doesn't currently address that problem well for stores > of disjoint keys (see https://golang.org/issue/21035). > > That said, if you're spawning a goroutine per write, you've already got > enough contention (on the scheduler) that any other synchronization > overhead is unlikely to matter. > > As you say: show me the code! The example you gave is simple enough that > it's not even clear why you need a map — a slice or channel would suffice. > (Personally, I'd be inclined to use a slice: > https://play.golang.org/p/jpS06KFNbv) > > So a more realistic use case would help: what do you want to do with this > map when you're done with it? > -- 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.
Re: [go-nuts] Re: concurrent write-only to map ok?
Show me the code! :) Here's mine: https://play.golang.org/p/ZwAlu5VuYr -- 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.
[go-nuts] Re: concurrent write-only to map ok?
Like Mr Pryczek, I'd be concerned that - the performance will be pessimized for this case, and - the approach is un-go-ish. Share memory by communicating is a Go idiom: send updates to a goroutine via a pipe, and by construction let the map never be written by others. It's more work to think about, but less to actually do (:-)) and a good introduction to the class of gopherish approaches. --dave -- 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.
[go-nuts] Re: concurrent write-only to map ok?
So many good answers! Lots of different ways to accomplish this. I'll say that in this specific case, which is does not require every ounce of performance, syncmap is by far the simplest and least amount of code, so readability wins on this one. -- 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.
[go-nuts] Re: concurrent write-only to map ok?
I think using standard sync'ed map may be bad idea for this use case (write-only access), especially taking into account that it's optimized for read access and stable keys, so each write will acquire mutex anyway. if nothing is read from that map during the threads run, it should be probably much better to assign single map for every thread and at the end, copy/merge the results to single "output" using mutex or rwmutex. This way you can acquire mutex once per thread, acquiring it for every write from multiple threads (which is what sync/map will do) is a performance killer. W dniu piątek, 13 października 2017 20:05:56 UTC+2 użytkownik Alex Buchanan napisał: > > Basically, I want to spawn a goroutine per object, objects have unique > IDs, and I want each routine to write its results to a shared map. Nothing > will be reading from the map while the goroutines are running. > > Is this safe? > > Thanks > -- 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.
