Since a concurrent map (aka. Dictionary aka. Hashtable) is a lot more complex and slow than a non concurrent one, it's very very unlikely that Go would ship with its standard map type being a concurrent one. It would be a huge waste.
More likely there is a separate concurrent map type. It's exactly the same in other languages with mutable collections (Java, .NET, C++, ...).
We should develop a system where maps are unsynchronised by default, but when you access them from a second thread they are then converted transparently by the runtime to a thread-safe implementation.
A half-solution could be using very lightweight synchronization (e.g. a MVar containing an unsynchronized map) that's later converted as you describe, but it would still incur some cynchronization overhead (even for single-threaded use).
You could then profile allocation sites so that if a map is frequently converted to concurrent, you then start allocating it as concurrent in the first place.
Although I could imagine a similar "signaling" mechanism, where each thread would periodically read a single snychronized variable, to check if there's any additional "re-synchronisation" work it needs to do. But I'm guessing that CPUs are implemented that way anyways.
No nobody needs to wait for a GC, but we use the same mechanism that the GC does.
> Although I could imagine a similar "signaling" mechanism, where each thread would periodically read a single synchronised variable
And that's how the GC already works. Except instead of a variable normally a 'test' instruction is used on a page of memory, and instead of setting the variable, the permission on the page are changed triggering a page fault.
Which GCs do that? The only one I know is Azul's Pauseless JVM GC, but that's a kind of a special case, given that it needs support from the kernel.
http://dl.acm.org/authorize.cfm?key=N98613
Also note that Azul almost certainly has the same mechanism to do things like stop the world for dynamic class loading, even if it isn't using it for GC when running the pauseless collector.
And Section 4 and 5 of this paper talks a bit more about it's implemented http://chrisseaton.com/rubytruffle/icooolps15-safepoints/saf....
Multithreading isn't something that should be implicit. Either you design your whole module/library/application around to be used from multiple threads (with all the extra work for synchronization and typically also well defined thread boundaries) or you stay with single threading.