Subj : Re: recursive mutexes To : comp.programming.threads From : Uenal Mutlu Date : Thu May 19 2005 01:01 pm "David Butenhof" wrote > 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.) I must admit I have yet to work on a multiprocessor machine. I assume you are thinking of the CPU cache stuff, but this is up to the CPU designers, I believe they will solve the problem (if not already done so) to reduce the overheads of CPU switching and thread switching. > 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. Hmm. to each his/her own. But since we are in comp.programming.threads ... > 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. For me these dinosaur arguments don't count (anymore). Today's demands are much different than what it was some 10 yrs ago or so. In future concurrency (esp. multi-threading) is the way to go, even the C++ designers have seen this and plan to add it into the language. > 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". Sorry, there is no alternative to not use threads in most practical applications of today. > 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. I haven't claimed that (yet), but logic would dictate to think indeed so, though I haven't researched it yet (OTOH if HP would like to lend me such a multiprocessor machine then I would do :-) .