et al. showed that lock-free algorithms are practically
> wait-free. I suppose the same could be shown for several concurrent
> algorithms that are not strictly lock-free. So it is not so much important
> whether an algorithm is lock-free or not, but whether it works well in
> practice for the use case
assumptions most of the time.
>
> Lock-freedom or wait-freedom is valuable is when you need strong
> worst-case guarantees (real-time scheduling for example) or cannot rely on
> the OS (because you might be writing one or you have specific
> fault-tolerance requirements).
>
> --
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 Fr
ing to share my joy with someone... But I think I
must look another place.
Thanks for all.
Em sáb., 18 de jan. de 2020 às 13:10, Manuel Pöter
escreveu:
> Hi bittnkr,
>
> I am still not sure whether you are interested in a meaningful discussion
> or not (but most of your responses con
found is only 64
positions. Take a look on the benchmarks
<https://github.com/bittnkr/uniq#benchmarks---measuring-the-flow>
I've update the docs <https://github.com/bittnkr/uniq> and I think it is
clearer now.
Please run the code, stress it, increase the number of threads, reduce a
orithms are practically
> wait-free. I suppose the same could be shown for several concurrent
> algorithms that are not strictly lock-free. So it is not so much important
> whether an algorithm is lock-free or not, but whether it works well in
> practice for the use case it is designed for
ot mean that they do
>> not scale.
>>
>> Alistarh et al. showed that lock-free algorithms are practically
>> wait-free. I suppose the same could be shown for several concurrent
>> algorithms that are not strictly lock-free. So it is not so much impo
> 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-
you see a lock there?
Please
Em seg, 13 de jan de 2020 04:35, Dmitry Vyukov escreveu:
> +lock-free group again, please don't drop it
>
> On Mon, Jan 13, 2020 at 8:19 AM bittnkr wrote:
> >
> > If a thread dies at that point, my entire system is broken...
>
>
