* Robert Engels [191112 13:44]:
> Sorry, at work so I need to use the 'web mail' interface and it
> doesn't appear to be including them when I reply.
Understood. I'll just try to follow the threading as best as I can.
...Marvin
--
You received this message because you are subscribed to the Go
ang/go/issues/5045
>>
>> -Original Message-
>> >From: Marvin Renich
>> >Sent: Nov 12, 2019 11:30 AM
>> >To: golang-nuts
>> >Subject: Re: [go-nuts] What is the correct way to access/modify slice
>> >elements concurrently
>>
; >Sent: Nov 12, 2019 11:30 AM
> >To: golang-nuts
> >Subject: Re: [go-nuts] What is the correct way to access/modify slice
> >elements concurrently
> >
> >[I almost missed this post because you did not reply to the thread.]
> >
> >* Robert Engels [191
This is not the issue I am referring to, I am referring to
https://github.com/golang/go/issues/5045
-Original Message-
>From: Marvin Renich
>Sent: Nov 12, 2019 11:30 AM
>To: golang-nuts
>Subject: Re: [go-nuts] What is the correct way to access/modify slice elements
&
[I almost missed this post because you did not reply to the thread.]
* Robert Engels [191108 11:41]:
> See https://github.com/golang/go/issues/10958 for using atomics in
> tight/busy-wait loops.
This doesn't have anything to do with atomics. Atomic operations are
just one of many, many things
-Original Message-
>From: burak serdar
>Sent: Nov 8, 2019 9:19 AM
>To: golang-nuts
>Subject: Re: [go-nuts] What is the correct way to access/modify slice elements
>concurrently
>
>On Fri, Nov 8, 2019 at 7:55 AM Marvin Renich wrote:
>>
>> * bur
On Fri, Nov 8, 2019 at 7:55 AM Marvin Renich wrote:
>
> * burak serdar [191108 08:42]:
> > I was thinking about this. In general, it should be safe to replace
> >
> > Lock()
> > read/write one value
> > Unlock()
> >
> > with
> >
> > AtomicRead/Write
> >
> > Is that correct? The go memory model do
* burak serdar [191108 08:42]:
> I was thinking about this. In general, it should be safe to replace
>
> Lock()
> read/write one value
> Unlock()
>
> with
>
> AtomicRead/Write
>
> Is that correct? The go memory model does not say anything about this.
Yes.
While others have argued that the GM
Almost always, but it is very difficult as most times you are not really
working with a single value (there are implied dependencies). These sort of
solutions fall under “lock free” structures/algorithms - and they are
fascinating to learn about.
> On Nov 8, 2019, at 7:42 AM, burak serdar wro
On Fri, Nov 8, 2019 at 6:25 AM Marvin Renich wrote:
>
> * Kasun Vithanage [191107 23:47]:
> > type Foo struct {
> > Alive bool
> > }
> >
> > type Bar struct {
> > Foos []*Foo
> > }
> >
> > func (b *Bar) CheckFoosAlive() {
> > for i := 0; i < len(b.Foos); i++ {
> > if b.Foos[i].Alive {
* Kasun Vithanage [191107 23:47]:
> type Foo struct {
> Alive bool
> }
>
> type Bar struct {
> Foos []*Foo
> }
>
> func (b *Bar) CheckFoosAlive() {
> for i := 0; i < len(b.Foos); i++ {
> if b.Foos[i].Alive {
> fmt.Println("Alive")
> }
> }
> }
>
> func (b* Bar) MarkFooStat
11 matches
Mail list logo
