Subj : Re: recursive mutexes
To   : comp.programming.threads
From : Chris Thomasson
Date : Wed May 18 2005 12:21 pm

> Lock-free is NOT a 100% solution. (There have been fanatics who denied 
> that and made the whole thing look a bit unsavory...

The old SenderX...  I have seen the light!

:)

I am finding that an effective marriage between lock-based and lock-free can 
provide optimal solutions for all sorts of well-known problems...




> It's overly complicated for many simple jobs, though a lot of people are 
> working on packages (particularly C++ template libraries) to make it 
> easier and more portable.

Yes. Once you get the required infrastructure up and running, hiding a 
lock-free algorithm behind a simple API can be relatively easy. As for 
portability, I still don't trust C compilers. They can reorder instructions 
under your nose. This is why I try to keep all of my lock-free code in 
externally assembled functions. This can limit the number of chances a C 
compiler has to screw you over:

http://groups-beta.google.com/group/comp.programming.threads/msg/423df394a0370fa6

;)




> Still, it DOES provide substantial benefit not only in straightline 
> performance but also in process and system throughput for many common 
> tasks when used carefully and properly.
>
> Lock-free has different contention properties. There ARE algorithms where 
> the SPEEDUP due to lock-free will DECREASE application throughput. But 
> that's not because lock-free is inherently bad, or slow; only because the 
> improvement has shifted the bottleneck to other parts of the application 
> that lack scalability (and may often be harder to fix). In tuning a 
> commercial thread library, I've had personal experience with this effect 
> in many commercial applications; and they don't hesitate to complain that 
> the new release "slowed their code". It IS a risk, and can require 
> substantial design work to overcome. But it just means the application 
> design was bad in the first place; and if you're willing and able to fix 
> it you can benefit enormously from the previously untapped concurrency.

Well said.




> If you want to investigate the relationships (both cooperative and 
> adversarial) between lock-free and locked design strategies, google 
> through the archives of this newsgroup -- we've had some quite "lively" 
> discussions on that topic over the years. ;-)

The SenderX files?

http://groups.google.de/group/comp.programming.threads/browse_frm/thread/d062e1bfa460a375/3461ab7dd927a6ec?group=comp.programming.threads#3461ab7dd927a6ec

;)




-- 
http://appcore.home.comcast.net/
(portable lock-free data-structures)

.