On 3/30/2013 10:58 PM, David Symonds wrote:
Yes, but that's mainly due to no-one having changed the
*implementation* details of the multi-word builtin types. That doesn't
imply anything about the language itself.
See "http://research.swtch.com/gorace" for how to create an invalid
pointer exploit using a multi-threaded Go program. We've been through
this before. There's a lot of denial about Go's concurrency safety.
No-one denies that the current implementation has
not-safe-for-concurrent-use builtin types, but that's an artifact of
By design, Go maps are not thread-safe. Locking overhead
was considered to be too high. It might be possible to implement
maps using atomic operations such as swap and compare-and-swap.
Resizing is a headache, but if the entire map was redirected
as Russ Cox proposes for slices, then resizing by building
a new (bigger) map and replacing the old one in its entirety works.
This is memory-safe and lock free, but not concurrency-correct.
Two threads could be updating the same map during a resize, and
the updates from only one of them will be kept. Still, it's
far better than the current "crash on concurrent update" implementation.
Russ Cox's proposed fix for slices costs an extra redirection
on each slice access. This might be feasible for number-crunching
work if Go supported multidimensional slices. (Then you redirect
once per array, not once per row.) Since multidimensional slices
would also reduce subscript checking overhead (all rows are the
same length), it would make sense to put that in at the same time
slices were made thread-safe. This is in an area where performance
matters - inner loops of array operations. So it's worth getting right.
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 firstname.lastname@example.org.
For more options, visit https://groups.google.com/groups/opt_out.