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 <bser...@computer.org> wrote:
>
>> On Fri, Nov 8, 2019 at 6:25 AM Marvin Renich <m...@renich.org> wrote:
>>
>> * Kasun Vithanage <alanka...@gmail.com> [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) MarkFooStatus(index int, status bool){
>>> // after bound checking
>>> b.Foos[index].Alive = status
>>> }
>>
>> Volker's answer is very good, but for the simple case where Alive is (or
>> can be) a type that is handled by the atomic package, that is almost
>> certainly the best approach.
>
> 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.
>
>
>>
>> If the Foo struct is complicated, and you have lots of non-overlapping
>> access to b.Foos (with the occasional overlapping access), I strongly
>> suspect that putting a mutex in Foo and using that will give you the
>> best results.
>>
>> As Volker said, try several different approaches, and measure with loads
>> approximating your real-world scenario. Alternatively, implement the
>> approach that you think is easiest to maintain (from a source code POV),
>> and test to see if the performance is acceptable under load. If it is,
>> don't bother trying to optimize.
>>
>> ...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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/20191108132521.bkrbxj2lv7wpinuo%40basil.wdw.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAMV2RqoGKG8FAqxn-M_E9hN3%2BzqX1UABWmdHu9w6rneKCu%2BsuA%40mail.gmail.com.
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/58E8A687-9E28-4F39-9EF2-B095D1D80265%40ix.netcom.com.
