Subj : Re: recursive mutexes To : comp.programming.threads From : David Butenhof Date : Wed May 18 2005 04:27 pm Uenal Mutlu wrote: > "Markus Elfring" wrote > >>>You are putting operations into 2 categories: >>> 1) operations which can be done only if the object is locked >>> 2) operations which can be done only if the object is not locked >>> >>>This is unneccessary complication, and it's dangerous. >>>My point of view is: all operations on a shared object can be done only >>>in a locked state (#1 above). So one has to forget #2 and never assume to do #2. >>>An object can be modified only in a locked state, otherwise wait or >>>give up your time-slice back to the schedular. >>>The result is: simplication, safety, speed. >> >>How does your statement fit to existing lock-free algorithms? > > We were talking about locking. > Lock-free shared access is IMO an illusion, usabe for some very small > and limited cases only, but not for 99.9% of practical requirements. > And IMO they are also slower than a method which uses locking, even > if this might sound counter-intuitive. Lock-free is NOT a 100% solution. (There have been fanatics who denied that and made the whole thing look a bit unsavory... but I think we're all long over that. I thought we were past the fanaticism on the other side, too; but maybe not.) 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. 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. 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. ;-) -- 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 .