Re: [lock-free] Re: 3-thread consensus.
> So I guess your opinion is just as good? :-)
No, I know my facts are better.
I'm sure my solution is lock free, because it's O(1) and have no leaks.
If you can't see the same, what can I do?
Em sex, 17 de jan de 2020 12:58, Nitsan Wakart escreveu:
> "everyone has it own ideas of what means to be lock free. " - So I guess
> your opinion is just as good? :-)
> If we are willing to redefine lock-free, we can call anything lock-free.
> Manuel provided you with the accepted view, you seem to think those are
> just opinions.
> If there's no agreement on what the term means the rest of the discussion
> is pointless, which is why Dmitry asked you: "what is your definition of a
> lock-free algorithm?" when he realized you are using your own definition
> (and then probably lost interest, given the pointlessness).
>
>
> On Fri, Jan 17, 2020 at 4:02 PM bittnkr wrote:
>
>> Dear Nitsan,
>>
>> Thanks for your message. You bring me a smile this morning.
>>
>> I really don't think so...
>>
>> I'm not manipulating the words to put an alien meaning on them.
>>
>> But instead, I'm trying to simplify a problem, considered impossible,
>> with a rather new, but simpler and concrete definition of a complex theme.
>>
>> Unfortunately, I've seen lots of different positions about the lock free
>> structures, so many that seems everyone has it own ideas of what means to
>> be lock free.
>>
>> This topic is a proof of this.
>>
>> We can debate for hours about the difference between lock-less or
>> lock-free and go nowhere, just chasing the tail. ;)
>>
>> Maybe because the lack of a simpler definition the solution is still
>> unknown.
>>
>> So, let's put some bases and premises to find a common background:
>>
>> Suppose you have 2 threads A&B incrementing an atomic integer with
>> positive and negative random numbers. Producing a Brownian motion.
>>
>> Int X: Atomic =0
>>
>> A() {X += random ());
>> B() {X -= random ());
>>
>> C() {print(X)}
>>
>> I ask you: It this program lock free?
>>
>> It may be obvious to you that this operation is lock free. Because there
>> is no locks and we are using atomic increment.
>>
>> But why? What's the primal fact that makes this operation lock-free?
>>
>> If you add another 50 instances of A&B? What will happen with the
>> performance of the program, it will increase, decrease or neither?
>>
>> What is the O() of this program/operation?
>>
>> And if you change the code to update X using a mutex?
>>
>> What will happen to the performance when you add those additional
>> threads? And the O()?
>>
>> Em sex, 17 de jan de 2020 03:55, Nitsan Wakart
>> escreveu:
>>
>>> Dear Bittnkr,
>>> You are entitled to your own opinion, not your own facts.
>>> The fact is that lock-free is a concrete term that has a current
>>> meaning, one that Manuel has taken the time to collect from different
>>> authoritative sources. You seem to go for the Humpty Dumpty approach:
>>>"When I use a *word*," Humpty Dumpty *said*, in rather a scornful
>>> tone, "it *means* just what I choose it to *mean*—neither more nor
>>> less."
>>> This is good fun in a story book, not so productive in this context
>>> though. If you want lock-free to mean whatever you want it to mean, then I
>>> agree your queue is lock-free.
>>> ;-)
>>>
>>> On Thu, Jan 16, 2020 at 8:43 PM bittnkr wrote:
>>>
Dear Manuel,
When pointless people loose their arguments, they said that discussion
is pointless. ;D
I made the most right-to-the-point affirmation I ever made in my entire
life:
*The only requirement to a algorithm be lock-free is to be O(1).*
To me, this affirmation is obvious and self contained at the point to
be axiomatic.
I don't know about Harri's linked list, but this is my general point
about lock freedom.
Can you refute it?
Em qui, 16 de jan de 2020 05:16, Manuel Pöter
escreveu:
> Progress guarantees have nothing to do with algorithmic complexity!
> Take Harris' lock-free linked list
> - the list operations are
> definitely not O(1), but it is still lock-free.
> I am not sure if you really don't understand this, or if you are
> deliberately ignoring all comments trying to explain what lock-freedom
> usually means. Either way, this discussion seems rather pointless by
> now...
>
> On Thursday, 16 January 2020 01:47:49 UTC+1, bittnkr wrote:
>>
>>
>> > Your algorithm is lockless (i.e. without lock) but not lock-free
>> according to the definition of lock-freedom.
>>
>> You make me think if my cellphone is wireless or wirefree. :)
>>
>> Thinking carefully about, I got an axiom:
>>
>> An algorithm can be called lock-free if it's O(1).
>>
>> Condition necessary and sufficient.
>>
>>
>> Em qua, 15 de jan de 2020 07:36, Mamy Ratsimbazafy
>> escreveu:
>>
>>> The definition of obstructi
Re: [lock-free] Re: 3-thread consensus.
"everyone has it own ideas of what means to be lock free. " - So I guess
your opinion is just as good? :-)
If we are willing to redefine lock-free, we can call anything lock-free.
Manuel provided you with the accepted view, you seem to think those are
just opinions.
If there's no agreement on what the term means the rest of the discussion
is pointless, which is why Dmitry asked you: "what is your definition of a
lock-free algorithm?" when he realized you are using your own definition
(and then probably lost interest, given the pointlessness).
On Fri, Jan 17, 2020 at 4:02 PM bittnkr wrote:
> Dear Nitsan,
>
> Thanks for your message. You bring me a smile this morning.
>
> I really don't think so...
>
> I'm not manipulating the words to put an alien meaning on them.
>
> But instead, I'm trying to simplify a problem, considered impossible, with
> a rather new, but simpler and concrete definition of a complex theme.
>
> Unfortunately, I've seen lots of different positions about the lock free
> structures, so many that seems everyone has it own ideas of what means to
> be lock free.
>
> This topic is a proof of this.
>
> We can debate for hours about the difference between lock-less or
> lock-free and go nowhere, just chasing the tail. ;)
>
> Maybe because the lack of a simpler definition the solution is still
> unknown.
>
> So, let's put some bases and premises to find a common background:
>
> Suppose you have 2 threads A&B incrementing an atomic integer with
> positive and negative random numbers. Producing a Brownian motion.
>
> Int X: Atomic =0
>
> A() {X += random ());
> B() {X -= random ());
>
> C() {print(X)}
>
> I ask you: It this program lock free?
>
> It may be obvious to you that this operation is lock free. Because there
> is no locks and we are using atomic increment.
>
> But why? What's the primal fact that makes this operation lock-free?
>
> If you add another 50 instances of A&B? What will happen with the
> performance of the program, it will increase, decrease or neither?
>
> What is the O() of this program/operation?
>
> And if you change the code to update X using a mutex?
>
> What will happen to the performance when you add those additional threads?
> And the O()?
>
> Em sex, 17 de jan de 2020 03:55, Nitsan Wakart
> escreveu:
>
>> Dear Bittnkr,
>> You are entitled to your own opinion, not your own facts.
>> The fact is that lock-free is a concrete term that has a current meaning,
>> one that Manuel has taken the time to collect from different
>> authoritative sources. You seem to go for the Humpty Dumpty approach:
>>"When I use a *word*," Humpty Dumpty *said*, in rather a scornful
>> tone, "it *means* just what I choose it to *mean*—neither more nor less."
>> This is good fun in a story book, not so productive in this context
>> though. If you want lock-free to mean whatever you want it to mean, then I
>> agree your queue is lock-free.
>> ;-)
>>
>> On Thu, Jan 16, 2020 at 8:43 PM bittnkr wrote:
>>
>>> Dear Manuel,
>>>
>>> When pointless people loose their arguments, they said that discussion
>>> is pointless. ;D
>>>
>>> I made the most right-to-the-point affirmation I ever made in my entire
>>> life:
>>>
>>> *The only requirement to a algorithm be lock-free is to be O(1).*
>>>
>>> To me, this affirmation is obvious and self contained at the point to be
>>> axiomatic.
>>>
>>> I don't know about Harri's linked list, but this is my general point
>>> about lock freedom.
>>>
>>> Can you refute it?
>>>
>>> Em qui, 16 de jan de 2020 05:16, Manuel Pöter
>>> escreveu:
>>>
Progress guarantees have nothing to do with algorithmic complexity!
Take Harris' lock-free linked list
- the list operations are
definitely not O(1), but it is still lock-free.
I am not sure if you really don't understand this, or if you are
deliberately ignoring all comments trying to explain what lock-freedom
usually means. Either way, this discussion seems rather pointless by now...
On Thursday, 16 January 2020 01:47:49 UTC+1, bittnkr wrote:
>
>
> > Your algorithm is lockless (i.e. without lock) but not lock-free
> according to the definition of lock-freedom.
>
> You make me think if my cellphone is wireless or wirefree. :)
>
> Thinking carefully about, I got an axiom:
>
> An algorithm can be called lock-free if it's O(1).
>
> Condition necessary and sufficient.
>
>
> Em qua, 15 de jan de 2020 07:36, Mamy Ratsimbazafy
> escreveu:
>
>> The definition of obstruction-free, lock-free or wait-free is not a
>> guarantee of performance, it's a guarantee of progress, in particular
>> when
>> thread can dies (non-blocking algorithm
>> )
>>
>> In computer science ,
>>> an algorithm is called
>>> *
Re: [lock-free] Re: 3-thread consensus.
Dear Nitsan,
Thanks for your message. You bring me a smile this morning.
I really don't think so...
I'm not manipulating the words to put an alien meaning on them.
But instead, I'm trying to simplify a problem, considered impossible, with
a rather new, but simpler and concrete definition of a complex theme.
Unfortunately, I've seen lots of different positions about the lock free
structures, so many that seems everyone has it own ideas of what means to
be lock free.
This topic is a proof of this.
We can debate for hours about the difference between lock-less or lock-free
and go nowhere, just chasing the tail. ;)
Maybe because the lack of a simpler definition the solution is still
unknown.
So, let's put some bases and premises to find a common background:
Suppose you have 2 threads A&B incrementing an atomic integer with positive
and negative random numbers. Producing a Brownian motion.
Int X: Atomic =0
A() {X += random ());
B() {X -= random ());
C() {print(X)}
I ask you: It this program lock free?
It may be obvious to you that this operation is lock free. Because there is
no locks and we are using atomic increment.
But why? What's the primal fact that makes this operation lock-free?
If you add another 50 instances of A&B? What will happen with the
performance of the program, it will increase, decrease or neither?
What is the O() of this program/operation?
And if you change the code to update X using a mutex?
What will happen to the performance when you add those additional threads?
And the O()?
Em sex, 17 de jan de 2020 03:55, Nitsan Wakart escreveu:
> Dear Bittnkr,
> You are entitled to your own opinion, not your own facts.
> The fact is that lock-free is a concrete term that has a current meaning,
> one that Manuel has taken the time to collect from different
> authoritative sources. You seem to go for the Humpty Dumpty approach:
>"When I use a *word*," Humpty Dumpty *said*, in rather a scornful
> tone, "it *means* just what I choose it to *mean*—neither more nor less."
> This is good fun in a story book, not so productive in this context
> though. If you want lock-free to mean whatever you want it to mean, then I
> agree your queue is lock-free.
> ;-)
>
> On Thu, Jan 16, 2020 at 8:43 PM bittnkr wrote:
>
>> Dear Manuel,
>>
>> When pointless people loose their arguments, they said that discussion is
>> pointless. ;D
>>
>> I made the most right-to-the-point affirmation I ever made in my entire
>> life:
>>
>> *The only requirement to a algorithm be lock-free is to be O(1).*
>>
>> To me, this affirmation is obvious and self contained at the point to be
>> axiomatic.
>>
>> I don't know about Harri's linked list, but this is my general point
>> about lock freedom.
>>
>> Can you refute it?
>>
>> Em qui, 16 de jan de 2020 05:16, Manuel Pöter
>> escreveu:
>>
>>> Progress guarantees have nothing to do with algorithmic complexity! Take
>>> Harris'
>>> lock-free linked list - the
>>> list operations are definitely not O(1), but it is still lock-free.
>>> I am not sure if you really don't understand this, or if you are
>>> deliberately ignoring all comments trying to explain what lock-freedom
>>> usually means. Either way, this discussion seems rather pointless by now...
>>>
>>> On Thursday, 16 January 2020 01:47:49 UTC+1, bittnkr wrote:
> Your algorithm is lockless (i.e. without lock) but not lock-free
according to the definition of lock-freedom.
You make me think if my cellphone is wireless or wirefree. :)
Thinking carefully about, I got an axiom:
An algorithm can be called lock-free if it's O(1).
Condition necessary and sufficient.
Em qua, 15 de jan de 2020 07:36, Mamy Ratsimbazafy
escreveu:
> The definition of obstruction-free, lock-free or wait-free is not a
> guarantee of performance, it's a guarantee of progress, in particular when
> thread can dies (non-blocking algorithm
> )
>
> In computer science ,
>> an algorithm is called
>> *non-blocking* if failure or suspension
>> of any thread
>> cannot cause
>> failure or suspension of another thread;[1]
>>
>> for some operations, these algorithms provide a useful alternative to
>> traditional blocking implementations
>> . A
>> non-blocking algorithm is *lock-free* if there is guaranteed
>> system-wide progress
>> , and *wait-free*
>> if there is also guaranteed per-thread progress.
>>
>
> Your algorithm is l
