Re: Boost.Threads: Do we need all those mutexes?
" Thread-safety should not be a run-time configurable property." I think this is somewhat incorrect as absolutes usually are.
Well, I'll probably lose the fairly abstract discussion of general incorrectness of absolutes. :-) I just think that compile-time vs. run-time is a pragmatic choice. Why give the user an alternative with is dubious and likely incorrect? For that reason std::list does not provide operator[] even though it could. Surely, one could come up with his/her design that would "require" such an operator for std::list. Does it invalidate the decisions STL designers made? I do not think so. That is why I am suspicious of temptations to lump distinctly different functions of scoped_lock, try_lock and timed_lock into one universal blob. V.
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.
Batov, Vladimir wrote:
" Thread-safety should not be a run-time configurable property."
I think this is somewhat incorrect as absolutes usually are.
Well, I'll probably lose the fairly abstract discussion of general incorrectness of absolutes. :-) I just think that compile-time vs. run-time is a pragmatic choice. Why give the user an alternative with is dubious and likely incorrect? For that reason std::list does not provide operator[] even though it could. Surely, one could come up with his/her design that would "require" such an operator for std::list. Does it invalidate the decisions STL designers made? I do not think so.
That is why I am suspicious of temptations to lump distinctly different functions of scoped_lock, try_lock and timed_lock into one universal blob.
Well, as you point out, try_lock is like a timed_lock with time = 0, and lock is like a timed_lock with time = infinity, so why not give timed_lock both lock() and try_lock() methods as shorthand notation for lock(m, t=0) and lock(m, t=infinity)? The argument for try_lock not having a blocking lock() method, which you seem to stress more often, is much clearer; I'm much more inclined to agree with you there. Mike
participants (3)
-
Batov, Vladimir -
Matt Hurd -
Michael Glassford