Subj : Re: recursive mutexes To : comp.programming.threads From : David Butenhof Date : Wed May 18 2005 08:42 pm Chris Thomasson wrote: >>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! Are you seriously claiming that "Chris Thomasson == SenderX"? Fascinating. That would certainly explain some things... Huh. ;-) > :) > > 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: However, there are a lot of linkers that can do optimization and restructing at LINK time, too. A far better solution is a compiler that understands multithread visibility rules and does the right thing in the first place. Realistically, most C/C++ compilers are "close enough", though lock-free certainly stretches the limits further than simple pthread ops. Still, the atomic ops and fences tend to be call-outs or builtins (whether asm() or more specialized) that the compiler will treat as call-outs, and that buys you a lot if you're careful. Realistically, this may be almost as much as using assembly code buys you -- and with better readability. But then... to each their own paranoia, eh? I definitely understand "where you're coming from". In this context, though, I prefer staying at the higher level where at all possible... "trust... but verify". ;-) I look forward to a standardized C++ concurrent memory model. A standardized C++ threading API would be nice, too, if a useful model can survive the compromises; but the memory model is what we absolutely need, now. > 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? Catchy. I like it. ;-) > http://groups.google.de/group/comp.programming.threads/browse_frm/thread/d062e1bfa460a375/3461ab7dd927a6ec?group=comp.programming.threads#3461ab7dd927a6ec > > ;) -- Dave Butenhof, David.Butenhof@hp.com HP Utility Pricing software, POSIX thread consultant Manageability Solutions Lab (MSL), Hewlett-Packard Company 110 Spit Brook Road, ZK2/3-Q18, Nashua, NH 03062 .