Several sources, including this issue comment:
https://github.com/golang/go/issues/27544#issuecomment-419265234
state that a buffered channel of size 1 can be used as a trylock by
select'ing on it with a default case.
I was thinking about it and it seemed to me that with such an
implementation
, March 11, 2019 at 1:16:04 AM UTC-4, Ian Lance Taylor wrote:
>
> On Sun, Mar 10, 2019 at 7:54 PM shivaram via golang-nuts
> > wrote:
> >
> > Can users of sync/atomic assume that memory will initially be zeroed? Or
> is it necessary for a manual zeroing (using the
Can users of sync/atomic assume that memory will initially be zeroed? Or is
it necessary for a manual zeroing (using the atomic store operations) to
happen-before any reads?
Context: https://github.com/golang/go/issues/5045 has the suggestion that
"you shouldn't mix atomic and non-atomic access
a program where the same
reads and writes are performed with the sync.atomic primitives, or under a
mutex.
[1] https://blog.regehr.org/archives/490
[2] https://golang.org/doc/articles/race_detector.html
On Tuesday, March 20, 2018 at 3:19:48 PM UTC-4, Ian Lance Taylor wrote:
>
> On Tue, Mar 2
PM UTC-4, Ian Lance Taylor wrote:
>
> On Mon, Mar 19, 2018 at 5:46 AM, shivaram via golang-nuts
> > wrote:
> >
> > 2. The property that word-sized values are not subject to
> > interleaving/tearing is an implementation detail, rather than a
> guarantee of
e not subject to
interleaving/tearing is an implementation detail, rather than a guarantee
of the Go memory model?
On Monday, March 19, 2018 at 1:55:07 AM UTC-4, Ian Lance Taylor wrote:
>
> On Sun, Mar 18, 2018 at 9:47 PM, shivaram via golang-nuts
> > wrote:
> >
> > I
I noticed that internally, the language implementation seems to rely on the
atomicity of reads to single-word values:
https://github.com/golang/go/blob/bd859439e72a0c48c64259f7de9f175aae3b9c37/src/runtime/chan.go#L160
As I understand it, this atomicity is provided by the cache coherence
algorit
