RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
1. Oh, c'mon, I never implied that your design was "dubious and likely incorrect". It was said in the context of operator[] for std:list. 2. IMHO for a library to be accepted, embraced, popular, survive it has to be suitable/convenient/intuitive for 80% of the users. The library should not go out of its way to satisfy esoteric requirements of 20% at the expense of clarity/simplicity/good design. Or example, std:auto_ptr is not for everyone and not always work where I'd like it to work. It does not mean std::auto_ptr needs to sacrifice its efficient and minimalistic beauty to make me happy. Getting back to Boost.Threads I'd still like to see a compelling example where I'd need to declare try_lock but twist its intuitive functionality into behaving like scoped_lock (that is blocking until locked). -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Matt Hurd Sent: Wednesday, 30 June 2004 10:42 AM To: boost@lists.boost.org Subject: Re: [boost] Re: Boost.Threads: Do we need all those mutexes? On Wed, 30 Jun 2004 10:17:04 +1000, Batov, Vladimir <vladimir.batov@ca.com> wrote:
Why give the user an alternative with is dubious and likely incorrect?
It is a pattern of need for multithreaded programming where I work to require single and multithreaded awareness for objects where performance excludes the option of using separate object instances. I don't think the design is dubious or incorrect it is mandated by the business requirements. Though most of my designs usually are incorrect or dubious ;-) I just call those tactical :-) matt. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Batov, Vladimir" <Vladimir.Batov@ca.com> writes:
1. Oh, c'mon, I never implied that your design was "dubious and likely incorrect". It was said in the context of operator[] for std:list.
This is getting a bit heated. Please don't let this get out of control. Thanks -- Dave Abrahams Boost Moderator
Batov, Vladimir wrote:
Getting back to Boost.Threads I'd still like to see a compelling example where I'd need to declare try_lock but twist its intuitive functionality into behaving like scoped_lock (that is blocking until locked).
In the need of extreme memory efficiency and speed: I already have, from prior use, a scoped_try_lock 'l' around my mutex, currently unlocked. I need to lock my mutex in a blocking fashion. I do not wish to pay the memory and time cost to create an instance of scoped_lock just to do this. I therefore call 'l.lock()' and not 'l.try_lock()'. I don't know that it's compelling, but it is an example. I understand your arguments for keeping the interface clean, but there are legitimate reasons for wanting a blocking lock operation on a TryLock. Constructor parameters are, admittedly, a different discussion, and most of them boil down to syntactic sugar for a non-locking constructor and a call to some locking operation, blocking or otherwise. But (IMO) it's a useful syntactic sugar that *can* if used properly make programs less cumbersome to construct without sacrificing correctness or clarity. -- Christopher Currie <codemonkey@gmail.com>
participants (2)
-
Batov, Vladimir -
Christopher Currie -
David Abrahams