| |||||||||||||
Van Rossum: Python is not too slow (InfoWorld)Van Rossum: Python is not too slow (InfoWorld)Posted Mar 21, 2012 16:36 UTC (Wed) by cmccabe (guest, #60281)In reply to: Van Rossum: Python is not too slow (InfoWorld) by njs Parent article: Van Rossum: Python is not too slow (InfoWorld)
Golang has atomic operations, which imply memory barriers, and also pointers. See http://golang.org/pkg/sync/atomic/ This is something that actually exists now, not just in theory.
As far as I can see, you should be able to use the CompareAndSwapUintptr operation to get the update-side memory barrier you need for RCU. Then you should be able to have reader threads read the pointer value normally, without a memory barrier, and get whatever they get.
In Go, you have garbage collection, so you can forget all about fooling with grace periods and so forth. Just update the pointer.
(Log in to post comments)
Van Rossum: Python is not too slow (InfoWorld) Posted Mar 21, 2012 16:53 UTC (Wed) by khim (subscriber, #9252) [Link] In Go, you have garbage collection, so you can forget all about fooling with grace periods and so forth. Just update the pointer. Not exactly. Quite often things like RCU are used for performance-critical tasks. The fact that language is built around GC means that now you not only need to worry about grace periods but you must convince GC to [roughly] obey them. YMMV: in some cases it may all “just work”, in some other cases you'll spend huge amount of time taming GC (and then everything will break once GC will be changed in your implementation). In fact non-optional GC is my biggest gripe with go.
Van Rossum: Python is not too slow (InfoWorld) Posted Mar 21, 2012 17:05 UTC (Wed) by njs (guest, #40338) [Link]
Ah, thanks! I missed those because they aren't mentioned on the Go memory model page: http://golang.org/doc/go_mem.html
|
|||||||||||||