Re: Lockfree or not to lockfree that's the question !

"Chris Thomasson" <cristom@xxxxxxxxxxx> wrote in message news:KvqdnV4xELvnwx3anZ2dnUVZ_rSrnZ2d@xxxxxxxxxxxxxx
"David Schwartz" <davids@xxxxxxxxxxxxx> wrote in message news:f2636424-ee26-435b-9235-76a226f3c67d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Jan 5, 1:48 pm, Dave Butenhof <david.buten...@xxxxxx> wrote:

Indeed; so then can we stick to concrete and objective advice for
archetypical workloads and tasks and avoid the religious
overgeneralizations entirely? ;-)

I think I've avoided religious overgeneralizations. I think it's fair
to say "X is bad because Y" when Y is a serious downside to X, even if
that doesn't make X objectively always bad.

If it's not those comments you are talking about, I'm not sure what
is. I simply presented a list of lock-free algorithms downsides. My
post didn't really contain any advice. Its sole purpose was to make
sure people understood the downside of lock-free algorithms.
[...]

Explain in detail how spinning on an adaptive mutex's internal state _fundamentally_ differs from spinning on a CAS failure wrt lock-free algorithms in general? IMVHO, its good to keep in mind that more than one mutex implementation decides to spin a little before deferring to the operating system... So be it as locks are essential to many lock-free algorithms indeed. Think writer-side of a low-overhead reader-pattern...

A little spin on the mutex is fine, as it can increase performance somewhat by turning things into a "temporary" spinlock-and-backoff semantics before the "ultimate" slow-path is hit, thus delegating to the kernel waitset that happens to be assigned to said mutex synchronization logic...

Here is a "hint": The CAS wrt lock-free is spinning an _actual_application _data_, while the CAS wrt mutex is spinning on its proxy private/internal state... Sometimes you only need to atomically modify a word or two...

Basic fundamental difference; no?

.

Relevant Pages

  • Re: Lockfree or not to lockfree thats the question !
    ... I simply presented a list of lock-free algorithms downsides. ... sure people understood the downside of lock-free algorithms. ... A little spin on the mutex is fine, as it can increase performance somewhat by turning things into a "temporary" spinlock-and-backoff semantics before the "ultimate" slow-path is hit, thus delegating to the kernel waitset that happens to be assigned to said mutex synchronization logic... ...
    (comp.programming.threads)
  • Re: FreeBSD 5.2.1: Mutex/Spinlock starvation?
    ... > they sleep on contention rather than spinning. ... of overal cpu)? ... > such as the change to proc.h to make grabbing and releasing the proc ... > several mutex operations from each system call, ...
    (freebsd-hackers)
  • Re: Lockfree or not to lockfree thats the question !
    ... I think I've avoided religious overgeneralizations. ... I simply presented a list of lock-free algorithms downsides. ... sure people understood the downside of lock-free algorithms. ... don't schedule uncontending threads the way locks do. ...
    (comp.programming.threads)
  • Re: duplicate read/write locks in net/pfil.c and netinet/ip_fw2.c
    ... >> In fact i don't understand why you consider spinning and sleeping ... > The major difference between sleeping and blocking ... > on a mutex is priority inheritance. ...
    (freebsd-arch)
  • Re: duplicate read/write locks in net/pfil.c and netinet/ip_fw2.c
    ... >> In fact i don't understand why you consider spinning and sleeping ... > The major difference between sleeping and blocking ... > on a mutex is priority inheritance. ...
    (freebsd-net)