Jan's comments about possible outcomes other than those outlined in
Sotirios' second post are correct. Using atomic.Value would synchronise
the values due to the introduction of a write barrier. I'm not omitting
much of the argument, you're just missing it.
Sorry, I'm done.
On Mon, 2019-05-27 at
You have conveniently omitted much of the argument, for example, like reading
Ander from a string containing Anderson due to improper synchronization - which
is clearly incorrect and what I was pointing out. The java refs are important
to this discussion since when everything is ref and under GC
In the post that I was replying to you told the OP to ignore incorrect
comments and then brought in the java world and stated that
synchronisation was not needed, only atomic operations. The comments by
previous posters were not incorrect and how things work in java is only
barely relevant here giv
I’m sorry if you think I put words in your mouth, I did not mean to.
Can you please explain what "Please don’t” means then? I took it at face value,
and that it was a affirmative response to “Don’t be clever."
> On May 27, 2019, at 7:33 AM, Dan Kortschak wrote:
>
> Please don't say I've said t
Please don't say I've said things I didn't. I did not dissuade someone
from understanding or using something. I quoted the memory model, and I
pointed out that the advice given by previous posters was not incorrect
as you claim. What you are reading them as saying may be wrong, but not
what they ar
They are not clever. They are foundational in high performance lock-free
structures and other techniques commonly found in HPC and HFT - and even the
linux kernel (RCU). This is a decent overview
https://www.cs.cmu.edu/~410-s05/lectures/L31_LockFree.pdf but a bit hard to
follow since it is sli
Please don't. Java is not relevant here and the advice given by other
prior to this post in the thread is not incorrect. Using atomic
operations (in this case it would be atomic.Value's Load and Store
methods) invokes a write barrier, which is fundamentally just a memory
synchronisation. In pkg syn
On Sun, 26 May 2019 at 19:17, Jan Mercl <0xj...@gmail.com> wrote:
> On Sun, May 26, 2019 at 8:05 PM Sotirios Mantziaris
> wrote:
>
> > From what i understand you propose to create a new object and switch out
> the old one with the new one using the atomic package of go.
>
> That cannot work. Stri
And for the OP, there are atomics defined for strings - so what I referred you
to is still valid.
> On May 26, 2019, at 4:21 PM, Robert Engels wrote:
>
> I said nothing to the contrary. I was referring to the structures the poster
> discussed - which are not heap allocated within an array whic
I said nothing to the contrary. I was referring to the structures the poster
discussed - which are not heap allocated within an array which differs from
Java objects.
I think you would be better served by doing more reading and listening and less
yelling.
> On May 26, 2019, at 3:25 PM, Wojci
On Sun, 26 May 2019 13:50:13 -0500
Robert Engels wrote:
> This is an advantage that Java offers over Go for concurrent programming.
> Since everything is reference you don’t face this distinction. Which is why
> most Go uses channels, which are implemented with locks.
It would be good and fruitf
* especially
> On May 26, 2019, at 1:51 PM, Robert Engels wrote:
>
> Using atomics, which is what I stated to do, avoids the data race and is Edie
> sully useful with weak atomics.
>
>> On May 26, 2019, at 1:37 PM, Sotirios Mantziaris
>> wrote:
>>
>> I was thrown of by the previous comment.
Thanks for the clarification Robert.
On Sunday, May 26, 2019 at 9:50:56 PM UTC+3, Robert Engels wrote:
>
> I was referring to updating a reference to a string, which can be updated
> atomically.
>
> This is an advantage that Java offers over Go for concurrent programming.
> Since everything is
Using atomics, which is what I stated to do, avoids the data race and is Edie
sully useful with weak atomics.
> On May 26, 2019, at 1:37 PM, Sotirios Mantziaris
> wrote:
>
> I was thrown of by the previous comment.
> I think i will create some "atomic" types that handle using mutexes with
>
I was referring to updating a reference to a string, which can be updated
atomically.
This is an advantage that Java offers over Go for concurrent programming. Since
everything is reference you don’t face this distinction. Which is why most Go
uses channels, which are implemented with locks.
I was thrown of by the previous comment.
I think i will create some "atomic" types that handle using mutexes with
setter and getter methods.
Thanks Jan
On Sunday, May 26, 2019 at 9:17:44 PM UTC+3, Jan Mercl wrote:
>
> On Sun, May 26, 2019 at 8:05 PM Sotirios Mantziaris
> > wrote:
>
> > From wha
On Sun, May 26, 2019 at 8:05 PM Sotirios Mantziaris
wrote:
> From what i understand you propose to create a new object and switch out the
> old one with the new one using the atomic package of go.
That cannot work. String is a multi word value. There's nothing in the
atomic package that can upd
>From what i understand you propose to create a new object and switch out
the old one with the new one using the atomic package of go.
If that is the case i cannot use it since i don't control the field
directly.
I am using the SetString method of the Value struct in the reflect package.
// SetS
Ignore the incorrect comments from the others. There are many valid cases where
relaxed concurrency rules apply and you don’t need synchronization just atomic
ops (and with certain platform this is not needed - eg java volatile)That is
why GC systems can outperform non GC systems in concurrent s
I understand, i have to synchronize access...
Coming from another language i had some guarantees on some assignments
mostly int. A string might be a issue here of course...
I have to refactor my code in order to make is safe.
thanks.
On Sunday, May 26, 2019 at 6:13:56 PM UTC+3, Jan Mercl wrote:
On Sun, 26 May 2019 07:03:35 -0700 (PDT)
Sotirios Mantziaris wrote:
> Let's assume that the string field Name has the value `Mr. Smith` and we
> change this to `Mr. Anderson` in the goroutine, what are the possible
> values that i could bet on a read?
> If these are either `Mr. Smith` or `Mr.
On Sun, May 26, 2019 at 4:03 PM Sotirios Mantziaris
wrote:
> Let's assume that the string field Name has the value `Mr. Smith` and we
> change this to `Mr. Anderson` in the goroutine, what are the possible values
> that i could bet on a read?
>
> If these are either `Mr. Smith` or `Mr. Anderso
Let's assume that the string field Name has the value `Mr. Smith` and we
change this to `Mr. Anderson` in the goroutine, what are the possible
values that i could bet on a read?
If these are either `Mr. Smith` or `Mr. Anderson` i am very ok with that
because i want the value to be eventually co
On Sun, May 26, 2019 at 3:45 PM Sotirios Mantziaris
wrote:
> Is there a chance that reading and assigning values might not be atomic?
Accessing a the full multi word value is non-atomic on most, if not
all architectures.
--
You received this message because you are subscribed to the Google Gro
i am working on a library for configuration named harvester(
https://github.com/taxibeat/harvester), which will be soon properly open
sourced, where i can dynamically reconfigure the configuration from an
outside system (consul).
The user provides a struct with some tags
type testConfig struct
25 matches
Mail list logo
