I am porting nodejs app to go Nodejs app runs on a single thread and there is no synchronization required I can't understand how atomic Goroutines are ? Can context be switched when I access map or only when I access os io or lock or channel ? Can I avoid excessive Locking with go if app would be single threaded? Thank you Max
On 2012/6/17 <max.seven.max@...> wrote: > I am porting nodejs app to go > Nodejs app runs on a single thread and there is no synchronization required > I can't understand how atomic Goroutines are ? > Can context be switched when I access map or only when I access os io or lock or channel ? > Can I avoid excessive Locking with go if app would be single threaded? A switch between goroutines may happen anytime you perform a memory allocation (which includes some variable declarations, conversion to interface types, the use of defer, and map insertions). I think stack allocations can also go through the same path. Rémy.
I am porting nodejs app to go
Nodejs app runs on a single thread and there is no synchronization required
I can't understand how atomic Goroutines are ?
Can context be switched when I access map or only when I access os io or lock or channel ?
Can I avoid excessive Locking with go if app would be single threaded?
Thank you
Max
If you're using net/http, each new HTTP request is in its own goroutine. Whenever different goroutines access the same map, you need locks. I wouldn't worry about the cost of using locks yet. (it's basically free, relatively). Just get it working first, then profile.On Sun, Jun 17, 2012 at 1:17 AM, <> wrote:I am porting nodejs app to go
Nodejs app runs on a single thread and there is no synchronization required
I can't understand how atomic Goroutines are ?
Can context be switched when I access map or only when I access os io or lock or channel ?
Can I avoid excessive Locking with go if app would be single threaded?
Thank you
Max
RSS Feed