Subj : Re: recursive mutexes To : comp.programming.threads From : David Butenhof Date : Thu May 19 2005 02:56 am Uenal Mutlu wrote: > "Sergei Organov" wrote > >>"Uenal Mutlu" writes: >> >>>"Sergei Organov" wrote >>> >>>>"Uenal Mutlu" >> I would say that it is even much easier to develop a complex system > and also much easier to maintain it by the use of recursive mutices. > Nevertheless, this seems to be a religious issue, so I do respect your > and other's view on this, but please try to respect my view and my preferance > for recursive mutices too, since I've researched this field and am a > prefessional developer with more than 15 yrs of experience, so > I too know of what I'm talking of. Besides this, I strongly believe the future > belongs to the recursive mutices for their simplicity and safety over > non-recursive mutices, esp. for the huge and complex requirements > nowadays and of the future. OK, here's a new thought. If you are in fact writing UNIPROCESSOR code with threads doing nothing more than slowing down your application through pointless context switches (that is, strictly as a "code structuring" mechanism), then, fine. You've got no concurrency in the first place, you want no concurrency, and recursive mutexes do little harm on top of the cycles you're wasting already. In that case I'll believe you. But if any of your code is intended for multiprocessor applications, take a look at the scalability. Do you run twice as fast with two times as many threads, or twice as slow? Have you ever looked? Extensive use of recursive locking is a sure way to prevent concurrency. (Note, I didn't say "recursive mutexes", but "recursive locking"... if your recursive mutexes are rarely locked recursively, you're just wasting straightline compute cycles with the extra recursion logic and they're essentially just slow normal mutexes... you would be better off USING normal mutexes for reliability and simplicity, but I'd be willing to leave THAT as a matter of personal taste.) Most of the people in this newsgroup do not use threads just to say they did; they use them because they care about concurrency and scalability on multiprocessor systems. Fundamentally uniprocessor thinking is not generally well received when disguised as something else. Sure, you can argue that recursive mutexes are easier to use. In one respect (and depending on your goals and and sensitivity), that's even true. But then, there are many respected computer scientists who argue against any use of threads for the same reason... plain old sequential programming is "easier". Threading is hard in a complicated system; all the more so if you care about throughput and scalability rather than just pretty code using cool functions. Your "easy" and "reliable" shortcuts simply run counter to the main point of using threads for most of us. Yet, on the other hand, one of the valid (though certainly not the strongest) reasons to use threads is indeed as a program structuring tool. And sometimes that's really all you need. And then the performance consequences aren't a big deal. If that's what you mean, just say so, and we can wind all this up really quick with a "gee, why didn't you say so", and "have a nice day". But, once again, if you're trying to claim that your recursively locked thread-per-client code SCALES even close to linearly on large multiprocessors... well, you'll have to prove it. And not with another load of doubletalk. -- 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 .