Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #3507 > unrolled thread

Re: Lockfreee algorithms...

Back to article view | Back to comp.programming

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Lockfreee algorithms... "Chris M. Thomasson" <no@spam.invalid> - 2013-06-21 14:24 -0700
    Re: Lockfreee algorithms... "Chris M. Thomasson" <no@spam.invalid> - 2013-06-21 22:03 -0700

#3507 — Re: Lockfreee algorithms...

> "aminer"  wrote in message news:kq2dje$dc7$1@dont-email.me... The problem 
> is worse with lockfree algorithms , i said
> before that they can higher the contention, and they can
> be slow when there is more retries, Hence lockfree algorithms
> are not perfectly scalable,  and more than that read the
> following:


IMVHO, this is total non-sense. You say a distributed rwmutex is better than
lock-free; see the problem here? What about distributed lock-free...

Anyway, you seem to think as if locking protocols are the only thing that
can be engineered to scale.

;^/ 

[toc] | [next] | [standalone]

#3509

>> "aminer"  wrote in message news:51C4F46D.9050009@toto.net...

> On 6/21/2013 2:24 PM, Chris M. Thomasson wrote:
> >> "aminer"  wrote in message news:kq2dje$dc7$1@dont-email.me... The
> >> problem is worse with lockfree algorithms , i said
> >> before that they can higher the contention, and they can
> >> be slow when there is more retries, Hence lockfree algorithms
> >> are not perfectly scalable,  and more than that read the
> >> following:
> >
> >
> > IMVHO, this is total non-sense. You say a distributed rwmutex is better
> > than
> > lock-free; see the problem here? What about distributed lock-free...
> >
> > Anyway, you seem to think as if locking protocols are the only thing 
> > that
> > can be engineered to scale.
> >
> > ;^/


> Distributed lockfree optimize more for cache coherency,
> and it eliminates contention , but if there is more
> retries it will slow the Distributed rwmutex.

You seem to be erroneously assuming that  a system of lock-free
algorithms is based on CAS-loops and/or must loop back around
during a failed CAS-loop. Keep in mind that a thread can do other
work in response to a failed CAS. In fact, a failed CAS can be
a fairly decent hint for a thread to try and do some other work...


> Distributed algorithm solve the problem of contention
> and it optimize more for cache coherency, so it scales better
> the distributed lockfree.

This make absolutely no sense whatsoever!


> If you want the distributed rwmutex to be perfectly scalable
> dont use distributed lockfree but use the distributed rwmutex with
> for example my RWLock algorithm to solve the problem of a lot of retries
> that ressemble contention.

A general purpose rwmutex, distributed or not, can be a massive
bottleneck and flood readers with cache coherency traffic generated
by the atomic RMW and associated memory barriers contained within
the rwmutex algorithm implementation itself.

FWIW, I somehow managed to pull off an algorithm that is completely
loopless, and CAS free. It can be distributed as well. However, when I
need extreme performance for reader threads, I would flush it down
the toilet and use something like RCU...

;^) 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web