Re: [go-nuts] Re: genmap: Generate thread-safe, type-safe maps easily

[Олексій Чечель]

But it would be the most bloodless way. Go is positioned to develop various
APIs and microservices. This is often associated with high loads (in my
practice - always). I tired of wrapping the map into structures.
Nevertheless, I would like to hear, in occasion of generics, how this would
simplify the work with the map.

вт, 11 лип. 2017 о 00:27  пише:

> I'm not sure it sets a good precedent adding more data structures to the
> language. we need generics
>
> On Sunday, July 9, 2017 at 10:23:42 PM UTC-5, Олексій Чечель wrote:
>>
>> I do not understand what prevents the authors of the language from
>> determining the thread-safe type *cmap*(name is taken for example) with
>> builtin mutex:
>>
>> *X: = cmap[int]string{}*
>> *Y: = make(cmap[string]interface{})*
>>
>>
>> *x, exists := X[10]**y, ok := Y["some"]*
>>
>>
>> In this case, the programmer might get a choice, use a fast but unsafe
>> map or slower (but with internal mutex) *cmap*. It would be with a
>> standard API, instead of stupid *sync/#Map
>> *
>>
>> They wrote: "grab a mutex would slow down most programs and add safety to
>> few". Ok, give me choise to use map or *cmap* with similar API.
>>
>> пʼятниця, 16 червня 2017 р. 12:26:04 UTC+7 користувач am...@ammar.io
>> написав:
>>>
>>> https://github.com/ammario/mapgen
>>>
>>>
>>> Features:
>>>
>>>- Supports any key/value pair supported by Go's native maps
>>>- Allows complex operations via Lock() and Unlock()
>>>- Generated code conforms to golint and gofmt
>>>- Allows custom types
>>>- Sensible default file name and map name
>>>
>>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/_7XcsQxGPi0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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] justforfunc: a Go YouTube series

[Francesc Campoy Flores]

Hi gophers,

Sorry to spam you, but I'll do it only once! Today I published the episode 
15 of a YouTube series 

 
I've been working on for a while.

I think it is becoming a quite good resource for gophers looking for best 
practices, code reviews, and some fun projects.
All of the code is of course open source at github.com/campoy/justforfunc.

You're invited to check it out, and send any feedback to 
form.justforfunc.com or directly to my email :)



Francesc

-- 
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: go test -S: repeated symbols in assembly

[Francesc Campoy Flores]

I can confirm that the behavior only happens on Mac, tried the same on 
Linux and the output contained each symbol only once.

https://github.com/golang/go/issues/20976


On Monday, July 10, 2017 at 3:21:23 PM UTC-7, Francesc Campoy Flores wrote:
>
> Even using tip I get the same behavior, I attached the output of running 
> the following command with tip
>
> go test -bench=Div -gcflags "-S" 2>& out.s
>
> goos: darwin
>
> goarch: amd64
>
> pkg: 
> github.com/campoy/go-tooling-workshop/3-dynamic-analysis/3-profiling/jic
>
> BenchmarkDiv-8   5 3.79 ns/op
>
> PASS
>
> ok  
> github.com/campoy/go-tooling-workshop/3-dynamic-analysis/3-profiling/jic 
> 2.301s
>
> On Monday, July 10, 2017 at 3:04:51 PM UTC-7, Francesc Campoy Flores wrote:
>>
>> Hi,
>>
>> I'm writing on compiler optimization and benchmarks, and one of the 
>> things I do is `go test -bench=. -gcflags "-S"`
>>
>> This outputs the generated assembly, which allows me to point out when a 
>> function call has ben inlined, or simply removed.
>>
>> The problem is that for this piece of code 
>> https://play.golang.org/p/dGdRN_wd1i, I get two definitions for 
>> BenchmarkDiv (see attached file), one that has a DIVSD instruction, the 
>> other that doesnt.
>>
>> What does this mean?
>>
>> Francesc
>>
>

-- 
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: Are functional options idiomatic

['Eric Johnson' via golang-nuts]

On Sunday, July 9, 2017 at 9:12:06 PM UTC+2, Anmol Sethi wrote:
>
> Hello everyone!
>
> I’m writing a new library where I need to be able to configure a struct. 
> This struct and its configuration will be accessed concurrently. One design 
> pattern I see throughout the standard library and community is to make the 
> struct and its configuration fields public but all other fields private. 
>

> e.g.
>
> type MyServer struct {
> ConfigureMe int
> usedInternally string
> }
>
> This nicely complements Go’s default values and is very terse to use. This 
> is exactly how structs such as http.Server and autocert.Manager (part of 
> the new acme library) are used.
>
> As aforementioned, the configuration fields in my struct need to be 
> accessed concurrently. My issue is that since the configuration fields are 
> public, they can be freely mutated by a package user and so a race 
> condition may occur. I’m not sure how big of an issue this is considering 
> its very unlikely that someone will mutate the struct once its being used 
> but the design feels a bit fragile to me.
>

As you point out, race conditions might be a problem. That depends whether 
your configuration involves maps, or if it involves multiple parts of the 
configuration that a client might need to change together. If that's the 
case, then don't do it that way. This depends, in part, on whether or not 
your object can be seamlessly reconfigured at any time.

Another way of configuration options that I've considered involves using 
shadow configuration. Let clients change publicly accessible fields, and 
shadow the former values. This approach might be useful if your service can 
only change the actual configuration at specific times. When you hit those 
points, check the configuration in the struct versus the one previously 
used. When different, change and update the shadowed version.
 

>
> In search of a better way, I thought about using a config struct but then 
> I found Dave Cheney’s post 
> https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis about 
> using functional options and now I’m thinking of using those. However, I 
> haven’t seen this API design used anywhere at all in any library I have 
> ever used (or in the standard library at all) so I was wondering whether or 
> not it’s idiomatic.
>

Seems idiomatic to me. However, it does bake in a particular pattern of 
configuration that can only be done once, with an initialization function, 
rather than configuration that can be updated at any time.

>
> I’m not sure if I’m being overly pedantic in my criticism of having the 
> configuration fields public in the struct. I don’t have too many 
> configuration fields so maybe functional options will be overkill.
>

Seems to me the two approaches satisfy different needs. Public fields of a 
structure imply full configurability on the fly - such as logging 
configuration, whereas Cheney's approach implies configuration at launch. 
You might, in fact, need to use both.
 

>
> I’m not really sure what I should go with now and I’ve hit a mental block 
> with my design. I’m hoping someone will have some thoughts on what approach 
> I should go with.
>

Start with simpler. If you can change configuration on the fly, but need to 
worry about race conditions, then provide a method to update the config 
regardless.

Eric

-- 
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: Iterate trough interface{} that stores map

[Nathan Kerr]

If you know what the map type is, use a type assertion:

for k, v := range variable.(map[string]interface{}) {
   //... 
}

If it could be one of several map types, use a type switch first.

If you don't know anything about the map type, I don't know what you think 
you could do with it because you don't know what the data means.

On Monday, July 10, 2017 at 7:27:24 PM UTC+2, Kiageng satria pamungkas 
wrote:
>
> How to do that? i recently figure how to iterate interface{} that stores 
> slice but not map using refelct
>

-- 
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: genmap: Generate thread-safe, type-safe maps easily

[ammar]

I'm not sure it sets a good precedent adding more data structures to the 
language. we need generics 

On Sunday, July 9, 2017 at 10:23:42 PM UTC-5, Олексій Чечель wrote:
>
> I do not understand what prevents the authors of the language from 
> determining the thread-safe type *cmap*(name is taken for example) with 
> builtin mutex:
>
> *X: = cmap[int]string{}*
> *Y: = make(cmap[string]interface{})*
>
>
> *x, exists := X[10]**y, ok := Y["some"]*
>
>
> In this case, the programmer might get a choice, use a fast but unsafe map 
> or slower (but with internal mutex) *cmap*. It would be with a standard 
> API, instead of stupid *sync/#Map *
>
> They wrote: "grab a mutex would slow down most programs and add safety to 
> few". Ok, give me choise to use map or *cmap* with similar API.
>
> пʼятниця, 16 червня 2017 р. 12:26:04 UTC+7 користувач am...@ammar.io 
> написав:
>>
>> https://github.com/ammario/mapgen
>>
>>
>> Features:
>>
>>- Supports any key/value pair supported by Go's native maps
>>- Allows complex operations via Lock() and Unlock()
>>- Generated code conforms to golint and gofmt
>>- Allows custom types
>>- Sensible default file name and map name
>>
>>

-- 
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] Iterate trough interface{} that stores map

[soederboy]

How to do that? i recently figure how to iterate interface{} that stores 
slice but not map using refelct

-- 
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] does Go memory model guarantee this program always prints 1?

[Marvin Renich]

* T L  [170710 12:35]:
> so this is guaranteed by Go memory model?
> 
> package main
> 
> import "fmt"
> import "sync/atomic"
> import "unsafe"
> 
> func main() {
> var x, y int32
> 
> var p = unsafe.Pointer()
> 
> atomic.AddInt32(, 1)
> atomic.AddInt32(, 1)
>
> if atomic.LoadInt32() == 1 {
> fmt.Println("x =", *(*int32)(p)) // always 1 if it is printed?
> }
> } 

Again, no concurrency.  Order is as written.

I've only used unsafe.Pointer once and in a way that was specifically
documented to work, and I have not otherwise researched it, so I may be
wrong here, but assuming the GC is guaranteed to update p if x moves,
then I believe this will always print "x = 1".

...Marvin

-- 
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] does Go memory model guarantee this program always prints 1?

[Marvin Renich]

* T L  [170710 12:32]:
> so this is guaranteed by go memory model?
> 
> package main
> 
> import "fmt"
> import "sync/atomic"
> 
> func main() {
> var x, y int32
> 
> atomic.AddInt32(, 1)
> atomic.AddInt32(, 1)
>
> if atomic.LoadInt32() == 1 {
> fmt.Println("x =", atomic.LoadInt32()) // always 1 if it is 
> printed?
> }
> } 

No concurrency here.  Order is as written.

...Marvin

-- 
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] does Go memory model guarantee this program always prints 1?

[Marvin Renich]

[Reply-To set; I don't need two copies of replies.]

* T L  [170710 12:31]:
> so this is guaranteed by Go memory model?
> 
> package main
> 
> import "fmt"
> import "sync/atomic"
> 
> func main() {
> var x, y int32
> go func() {
> atomic.AddInt32(, 1)
> atomic.AddInt32(, 1)
> }()
>
> if atomic.LoadInt32() == 1 {
> fmt.Println("x =", atomic.LoadInt32()) // always 1 if it is 
> printed?
> }
> } 

Asked and answered in your previous msg.  Yes, assuming the Go authors
agree that atomic operations guarantee non-concurrency.  Can we have
someone authoritative weigh in here?

...Marvin

-- 
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] does Go memory model guarantee this program always prints 1?

[T L]

On Monday, July 10, 2017 at 8:36:54 PM UTC+8, Jan Mercl wrote:
>
> On Mon, Jul 10, 2017 at 2:24 PM T L  
> wrote:
>
> > Aha, what I wanted to express is the execution orders of the two lines 
> may be randomized.
> >
> > atomic.AddInt32(, 1) 
> > atomic.AddInt32(, 1) 
>
> No, assuming those two lines are as written, ie. part of single function 
> and thus executed in a single/the same goroutine. Then the memory model 
> guarantees they are executed in order, ie. x will be updated before y. But 
> there's no such guarantee when the same variable x and y are observed in a 
> different, concurrently executing goroutine. To establish such ordering you 
> have to synchronize, only that gives you the H-B relation within the 
> synchronization participants.
>
> -- 
>
> -j
>

so this is guaranteed by Go memory model?

package main

import "fmt"
import "sync/atomic"
import "unsafe"

func main() {
var x, y int32

var p = unsafe.Pointer()

atomic.AddInt32(, 1)
atomic.AddInt32(, 1)
   
if atomic.LoadInt32() == 1 {
fmt.Println("x =", *(*int32)(p)) // always 1 if it is printed?
}
} 

-- 
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] does Go memory model guarantee this program always prints 1?

[T L]

On Monday, July 10, 2017 at 8:36:54 PM UTC+8, Jan Mercl wrote:
>
> On Mon, Jul 10, 2017 at 2:24 PM T L  
> wrote:
>
> > Aha, what I wanted to express is the execution orders of the two lines 
> may be randomized.
> >
> > atomic.AddInt32(, 1) 
> > atomic.AddInt32(, 1) 
>
> No, assuming those two lines are as written, ie. part of single function 
> and thus executed in a single/the same goroutine. Then the memory model 
> guarantees they are executed in order, ie. x will be updated before y. But 
> there's no such guarantee when the same variable x and y are observed in a 
> different, concurrently executing goroutine. To establish such ordering you 
> have to synchronize, only that gives you the H-B relation within the 
> synchronization participants.
>
> -- 
>
> -j
>

so this is guaranteed by go memory model?

package main

import "fmt"
import "sync/atomic"

func main() {
var x, y int32

atomic.AddInt32(, 1)
atomic.AddInt32(, 1)
   
if atomic.LoadInt32() == 1 {
fmt.Println("x =", atomic.LoadInt32()) // always 1 if it is 
printed?
}
} 

-- 
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] does Go memory model guarantee this program always prints 1?

[T L]

On Monday, July 10, 2017 at 8:36:54 PM UTC+8, Jan Mercl wrote:
>
> On Mon, Jul 10, 2017 at 2:24 PM T L  
> wrote:
>
> > Aha, what I wanted to express is the execution orders of the two lines 
> may be randomized.
> >
> > atomic.AddInt32(, 1) 
> > atomic.AddInt32(, 1) 
>
> No, assuming those two lines are as written, ie. part of single function 
> and thus executed in a single/the same goroutine. Then the memory model 
> guarantees they are executed in order, ie. x will be updated before y. But 
> there's no such guarantee when the same variable x and y are observed in a 
> different, concurrently executing goroutine. To establish such ordering you 
> have to synchronize, only that gives you the H-B relation within the 
> synchronization participants.
>
> -- 
>
> -j
>

so this is guaranteed by Go memory model?

package main

import "fmt"
import "sync/atomic"

func main() {
var x, y int32
go func() {
atomic.AddInt32(, 1)
atomic.AddInt32(, 1)
}()
   
if atomic.LoadInt32() == 1 {
fmt.Println("x =", atomic.LoadInt32()) // always 1 if it is 
printed?
}
} 

-- 
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: Random Number Generation in a given range

[alok . singh]

yep you are right ! fixed it thanks 
https://github.com/alok87/goutils/commit/9f5f19a65eedf1bc9be82ec3f3b42c92142b2b8e


On Monday, July 10, 2017 at 8:15:13 PM UTC+5:30, Jan Mercl wrote:
>
>
> On Mon, Jul 10, 2017 at 4:41 PM Alok Kumar Singh  > wrote:
>
> > in my usecasei use this to generate random slice everytime 
> > dont want the same result
> > using it to test my algos
>
> For that you need one only call to Seed at init().
>
> -- 
>
> -j
>

-- 
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: Random Number Generation in a given range

[Jan Mercl]

On Mon, Jul 10, 2017 at 4:41 PM Alok Kumar Singh 
wrote:

> in my usecasei use this to generate random slice everytime
> dont want the same result
> using it to test my algos

For that you need one only call to Seed at init().

-- 

-j

-- 
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: Random Number Generation in a given range

[Sebastien Binet]

Alok,

On Mon, Jul 10, 2017 at 3:04 PM, Alok Kumar Singh 
wrote:

> I have fixed it thanks
>

I wouldn't recommend using rand.Seed as you do: this defeats any attempt at
getting reproductible results.

-s

-- 
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] liteide x32.1 released

[visualfc]

Hi all.
LiteIDE x32.1 released!
This version fix x32 bug. The folder custom GOPATH support subfolder inherit 
parent folder setting. The gocode plugin support custom GOPATH setting. Dlv 
debugger change to headless mode and fix kill process bug. etc.

### 2017.7.7 Ver X32.1
* LiteIDE
* build config custom gopath support inherit parent path's  gopath setup
* GolangCode
* update gocode lib-path by build config custom gopath
* LiteEnv
* optimization check go enviroment
* LiteBuild
* build config custom gopath inherit parent path
* fix BuildAndRun kill old on window
* fix build config custom gopath action
* GolangPackage
* fix load package treeview error
* DlvDebugger
* dlv use headless mode
* fix dlv kill process

Sent from Gmail

-- 
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: Random Number Generation in a given range

[Alok Kumar Singh]

I have fixed it thanks

On Mon, Jul 10, 2017 at 9:54 AM, peterGo  wrote:

> Alok,
>
> Your import path "github.com/alok87/goutils/random" is not valid for "go
> get". The source is at "github.com/alok87/goutils/pkg/random".
>
> You write "for { rand.Seed(); rand.Intn(); }". Therefore, the range of
> values is not random.
>
> You write "arr[r] = rand.Intn(max) + min" which is incorrect.
>
> And so on.
>
> Peter
>
>
> On Sunday, July 9, 2017 at 3:02:43 PM UTC-4, alok@practo.com wrote:
>>
>> A python like range utility which can be used for this
>> https://github.com/alok87/goutils/blob/master/pkg/random/random.go
>> ```random.RangeInt(2, 100, 3)```
>>
>> On Wednesday, March 28, 2012 at 5:43:55 AM UTC+5:30, Guillermo Estrada
>> wrote:
>>>
>>> Hi, I've been reading some posts but I still have the same question.
>>>
>>> I need to generate a random number between a min and a max value of
>>> floats (Float64) for example:
>>>
>>> random(-0.001, 0.001)
>>>
>>> Is there any way pkg "math/rand" could do this using the Normal
>>> Distribution or such? Most Random generation on the pkg works in [0.0,1.0)
>>> The closest I found is:
>>>
>>> func (*Rand) NormFloat64
>>> 
>>> But I need a way to clamp that range into my own, any ideas? Thnx in
>>> advance!
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/_M-8hRpQs84/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Regards,

Alok Kumar Singh


Platform Engineering

+ 91 9880121029

-- 
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] does Go memory model guarantee this program always prints 1?

[Jan Mercl]

On Mon, Jul 10, 2017 at 2:24 PM T L  wrote:

> Aha, what I wanted to express is the execution orders of the two lines
may be randomized.
>
> atomic.AddInt32(, 1)
> atomic.AddInt32(, 1)

No, assuming those two lines are as written, ie. part of single function
and thus executed in a single/the same goroutine. Then the memory model
guarantees they are executed in order, ie. x will be updated before y. But
there's no such guarantee when the same variable x and y are observed in a
different, concurrently executing goroutine. To establish such ordering you
have to synchronize, only that gives you the H-B relation within the
synchronization participants.

-- 

-j

-- 
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] does Go memory model guarantee this program always prints 1?

[T L]

On Sunday, July 9, 2017 at 5:10:20 PM UTC+8, Jan Mercl wrote:
>
> On Sun, Jul 9, 2017 at 10:56 AM T L  
> wrote:
>
> > But I remember that the "happens-before relationship" is never written 
> down in any official Go documentation.
>
> https://golang.org/ref/mem#tmp_2
>
>
> -- 
>
> -j
>

Aha, what I wanted to express is the execution orders of the two lines may 
be randomized.

 atomic.AddInt32(, 1) 
 atomic.AddInt32(, 1) 


 

-- 
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.