[thread] Questions/concerns about recent thread lib changes
The thread lib has recently gone through drastic changes. These much needed changes are very welcome and I really appreciate Anthony's work and efforts. We use boost::thread heavily in our mission/performance critical application and the quality and stability of the boost::thread code is paramount to us. With the recent changes and what happened in that process, I felt that it is necessary to raise my concerns to the community. If these concerns have already been addressed and managed, I sincerely apologize for generating this noise and being paranoid. Specifically, my questions are: 1. Do changes in this magnitude warrant a mini-review? 2. Is it a good idea that the new implementation be reviewed by other boost threading experts such as Peter and/or Howard? Take it to the next level, does it make sense to have a peer review process for at least significant changes? Regards, Sean
Sean Huang wrote:
The thread lib has recently gone through drastic changes. These much needed changes are very welcome and I really appreciate Anthony's work and efforts. We use boost::thread heavily in our mission/performance critical application and the quality and stability of the boost::thread code is paramount to us. With the recent changes and what happened in that process, I felt that it is necessary to raise my concerns to the community. If these concerns have already been addressed and managed, I sincerely apologize for generating this noise and being paranoid.
I haven't been tracking all the recent changes specifically, but I think that at least some of them are to have boost.thread start tracking to something that looks more like the current proposals for c++0x. Specifically: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2320.html See also: http://lists.boost.org/Archives/boost/2007/10/128343.php for discussion of this. Note that n2320 is now being word-smithed and unless some critical problem arises should be added to the c++0x working paper before the next committee meeting. While at its core n2320 depends heavily on boost thread it differs in a number of ways.
Specifically, my questions are: 1. Do changes in this magnitude warrant a mini-review? 2. Is it a good idea that the new implementation be reviewed by other boost threading experts such as Peter and/or Howard? Take it to the next level, does it make sense to have a peer review process for at least significant changes?
My $0.02 -- mini-review of the threading changes can't hurt given the importance to the c++ community of getting the best possible threading api in c++0x. Jeff
Sean Huang wrote:
The thread lib has recently gone through drastic changes. [...]
Regarding the changes in boost::thread, I have a specific question too. It seems that the file boost/thread/win32/basic_timed_mutex.hpp forgets to include boost/detail/interlocked.hpp. It will cause some errors like 'BOOST_INTERLOCKED_EXCHANGE_POINTER': dentifier not found". Any one can confirm this, or do I miss something?
gchen <chengang31@gmail.com> writes:
Sean Huang wrote:
The thread lib has recently gone through drastic changes. [...]
Regarding the changes in boost::thread, I have a specific question too.
It seems that the file boost/thread/win32/basic_timed_mutex.hpp forgets to include boost/detail/interlocked.hpp.
It will cause some errors like 'BOOST_INTERLOCKED_EXCHANGE_POINTER': dentifier not found".
Any one can confirm this, or do I miss something?
You're right, so I've checked in a fix. I guess it was being included by something else in all the tests. Anthony -- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
Sean Huang wrote:
The thread lib has recently gone through drastic changes. These much needed changes are very welcome and I really appreciate Anthony's work and efforts. We use boost::thread heavily in our mission/performance critical application and the quality and stability of the boost::thread code is paramount to us. With the recent changes and what happened in that process, I felt that it is necessary to raise my concerns to the community. If these concerns have already been addressed and managed, I sincerely apologize for generating this noise and being paranoid.
I'm personally also a bit concerned, not as much for implementation changes as for possible interface and/or semantic changes. Being an optimist, I believe that by the time the Boost.Thread library is released as part of an official Boost release, the implementation should be of sufficient quality. What I don't want to do, however, is to change my existing client code because of interface/semantic changes. If there are breaking changes, my suggestions would be to put the new (or to preserve the old) code in a separate namespace.
Specifically, my questions are: 1. Do changes in this magnitude warrant a mini-review?
Why not?
2. Is it a good idea that the new implementation be reviewed by other boost threading experts such as Peter and/or Howard?
If a mini-review would take place, I'd be surprised if they didn't participate.
Take it to the next level, does it make sense to have a peer review process for at least significant changes?
No opinions on this one. / Johan
"Johan Nilsson" <r.johan.nilsson@gmail.com> writes:
Sean Huang wrote:
The thread lib has recently gone through drastic changes. These much needed changes are very welcome and I really appreciate Anthony's work and efforts. We use boost::thread heavily in our mission/performance critical application and the quality and stability of the boost::thread code is paramount to us. With the recent changes and what happened in that process, I felt that it is necessary to raise my concerns to the community. If these concerns have already been addressed and managed, I sincerely apologize for generating this noise and being paranoid.
I'm personally also a bit concerned, not as much for implementation changes as for possible interface and/or semantic changes. Being an optimist, I believe that by the time the Boost.Thread library is released as part of an official Boost release, the implementation should be of sufficient quality.
Thanks for the vote of confidence.
What I don't want to do, however, is to change my existing client code because of interface/semantic changes. If there are breaking changes, my suggestions would be to put the new (or to preserve the old) code in a separate namespace.
Which features are important to you? Breaking interface changes so far: * Lock types are now namespace level rather than nested typedefs. * There is no seperate try_mutex * scoped_lock constructors that take a bool parameter removed in favour of explict try_to_lock, defer_lock overloads. * timed_lock functions now take boost::system_time (a typedef to boost::posix_time::ptime from the date_time library) rather than xtime * call_once order of arguments has been reversed, pending addition of support for passing arguments to the once function. Backwards compatibility support: * Overload of call_once added with existing arguments, which forwards to new version * scoped_lock typedefs left in mutex types * try_mutex left as a typedef Breaking changes coming soon: * Condition variables changed in line with new C++0X thread proposal. Non-breaking changes coming soon: * Thread launching changed in line with new C++0x thread proposal. This shouldn't break existing code, as the existing thread interface is so narrow. Anthony -- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
Anthony Williams wrote:
"Johan Nilsson" <r.johan.nilsson@gmail.com> writes:
[snip]
What I don't want to do, however, is to change my existing client code because of interface/semantic changes. If there are breaking changes, my suggestions would be to put the new (or to preserve the old) code in a separate namespace.
Which features are important to you?
All that enable my code to compile and work as previously without changes? Also, having the POSIX thread implementation handling EINTR during sleeps would be great. I'm currently using a wrapper for calls to thread::sleep to avoid spurious wakeups.
Breaking interface changes so far:
* Lock types are now namespace level rather than nested typedefs.
No problem as there's the mutex::scoped_lock typedef compatibility.
* There is no seperate try_mutex
* scoped_lock constructors that take a bool parameter removed in favour of explict try_to_lock, defer_lock overloads.
I can appreciate the explicitness, but this is still a problem as the interface changes. I rarely use the option to not lock the mutex initially, but it has happened.
* timed_lock functions now take boost::system_time (a typedef to boost::posix_time::ptime from the date_time library) rather than xtime
If you are going to make a breaking change - why not add an time_duration overload, please? Even if almost everything is better than the current xtime interface, I've so far never had a requirement to use an absolute time for waiting or sleeping. Absolute times is most often just a real pain to use, and in its current implementation also misleading. (I've read the rationale in Programming with POSIX Threads, but I'm not convinced.) [snip remaining breaking + compatibility changes] I just came to the conclusion that there's no point in me commenting on all the changes. If I really have to, I can adapt our code to use the new threading interface even though I'd prefer not to. But - if the new stuff + the compatibility changes will all exist in the same namespace it feels like it's going to be a source of confusion, as there will be multiple ways of doing the same thing. Why not put the new thread implementation in e.g. boost::std0x::thread and have the current Boost.Thread delegate to the new implementation using an unchanged interface (wherever technically possible)? I'll read through the n2320 proposal as soon as I get some time. / Johan
Johan Nilsson wrote:
* timed_lock functions now take boost::system_time (a typedef to boost::posix_time::ptime from the date_time library) rather than xtime
If you are going to make a breaking change - why not add an time_duration overload, please? Even if almost everything is better than the current xtime interface, I've so far never had a requirement to use an absolute time for waiting or sleeping. Absolute times is most often just a real pain to use, and in its current implementation also misleading.
(I've read the rationale in Programming with POSIX Threads, but I'm not convinced.)
n2320 calls for interfaces with time_duration on all timed_lock functions. Only the condition variable adds an absolute time (eg: system_time) which is to handle spurious wakeups. Looking at the latest code on the trunk, I can see that Anthony hasn't switched the interface to handle time_durations in all cases, but he has in Mutex: class mutex { template<typename TimeDuration> bool timed_lock(TimeDuration const & relative_time); Jeff
Jeff Garland wrote:
Johan Nilsson wrote:
* timed_lock functions now take boost::system_time (a typedef to boost::posix_time::ptime from the date_time library) rather than xtime
If you are going to make a breaking change - why not add an time_duration overload, please? Even if almost everything is better than the current xtime interface, I've so far never had a requirement to use an absolute time for waiting or sleeping. Absolute times is most often just a real pain to use, and in its current implementation also misleading.
(I've read the rationale in Programming with POSIX Threads, but I'm not convinced.)
n2320 calls for interfaces with time_duration on all timed_lock functions.
What about sleep?
Only the condition variable adds an absolute time (eg: system_time) which is to handle spurious wakeups.
It's possible to handle spurious wakeups with relative times as well, perhaps just not perfectly (depending on underlying platform support). If the only way to perform a timed wait on a condition variable is by an absolute time, I believe the most common usage will be something like this (pseudocode): --- time now = microsec_clock::local_time(); time timeout = now + milliseconds(250); if (!cv.timed_wait(lk, timeout, my_pred())) { throw "Timed out!"; } --- Now, my intention is clearly to wait for a maximum, _relative_, time before something happens. I'm not interested in whether it occurs before a specific absolute time or not. Besides that, the above code is subject to race conditions (as the system time can be set at any time). Also, if this timed wait implementation is (as in Boost <= 1.34.1) internally converting to relatively timed waits, the interface is lying to me. If I use an absolute time as the time parameter, I'd expect the method not to return until the system time has actually reached that time - no matter if someone unexpectedly set the time forward one hour just before I call timed_wait above. Just my 0.02EUR. / Johan
Johan Nilsson wrote:
It's possible to handle spurious wakeups with relative times as well, perhaps just not perfectly (depending on underlying platform support). If the only way to perform a timed wait on a condition variable is by an absolute time, I believe the most common usage will be something like this (pseudocode):
--- time now = microsec_clock::local_time(); time timeout = now + milliseconds(250); if (!cv.timed_wait(lk, timeout, my_pred())) { throw "Timed out!"; }
You are missing a loop.
Peter Dimov wrote:
Johan Nilsson wrote:
It's possible to handle spurious wakeups with relative times as well, perhaps just not perfectly (depending on underlying platform support). If the only way to perform a timed wait on a condition variable is by an absolute time, I believe the most common usage will be something like this (pseudocode):
--- time now = microsec_clock::local_time(); time timeout = now + milliseconds(250); if (!cv.timed_wait(lk, timeout, my_pred())) { throw "Timed out!"; }
You are missing a loop.
I think you're missing the predicate "my_pred()". / Johan
Johan Nilsson wrote:
Peter Dimov wrote:
Johan Nilsson wrote:
It's possible to handle spurious wakeups with relative times as well, perhaps just not perfectly (depending on underlying platform support). If the only way to perform a timed wait on a condition variable is by an absolute time, I believe the most common usage will be something like this (pseudocode):
--- time now = microsec_clock::local_time(); time timeout = now + milliseconds(250); if (!cv.timed_wait(lk, timeout, my_pred())) { throw "Timed out!"; }
You are missing a loop.
I think you're missing the predicate "my_pred()".
You are right, I was. Relative timeouts do indeed make sense for the predicate version, if (1) you are willing to accept the inconsistency and (2) you are only concerned with use cases like the above where the timeout is not a deadline but a safety net. An additional relative timeout overload in the cases where it's appropriate could work, but the current templatization does not allow it unless concepts come into play.
Peter Dimov wrote:
Johan Nilsson wrote:
Peter Dimov wrote:
Johan Nilsson wrote:
It's possible to handle spurious wakeups with relative times as well, perhaps just not perfectly (depending on underlying platform support). If the only way to perform a timed wait on a condition variable is by an absolute time, I believe the most common usage will be something like this (pseudocode):
--- time now = microsec_clock::local_time(); time timeout = now + milliseconds(250); if (!cv.timed_wait(lk, timeout, my_pred())) { throw "Timed out!"; }
You are missing a loop.
I think you're missing the predicate "my_pred()".
You are right, I was. Relative timeouts do indeed make sense for the predicate version, if (1) you are willing to accept the inconsistency and (2) you are only concerned with use cases like the above where the timeout is not a deadline but a safety net.
I believe there are "relative" deadlines as well. Suppose you are receiving data that should arrive at a certain frequency; if that frequency is e.g. 20Hz, a reasonable value for emitting a data timeout warning could be 2 periods => 50*2 = 100ms (in this case, a background thread would put each data item in a common buffer when it arrives, and signal the cv for some other entity to process it). Sure, there're no guarantees that this will always work correctly on a "soft" realtime system - but in general this is perfectly reasonable (and acceptable) for many applications. Especially for in-house applications that run on computers dedicated for a specific purpose.
An additional relative timeout overload in the cases where it's appropriate could work, but the current templatization does not allow it unless concepts come into play.
Well, where would it not be appropriate? / Johan
Johan Nilsson:
I believe there are "relative" deadlines as well. Suppose you are receiving data that should arrive at a certain frequency; if that frequency is e.g. 20Hz, a reasonable value for emitting a data timeout warning could be 2 periods => 50*2 = 100ms (in this case, a background thread would put each data item in a common buffer when it arrives, and signal the cv for some other entity to process it).
You may well start out with a relative timeout value, but it's converted to an absolute deadline just once, at the start, on a high level that doesn't usually deal with thread primitives. Then you propagate the absolute deadline through code. Something like: bool f( abstime const & dl ) { return g( dl ) && h( dl ); } (guaranteed wait-free rollback on failed h omitted for simplicity :-) ). Even for the simple condvar wait case, you have a preceding mutex lock which needs to also respect the deadline. Relative timeouts on the primitive level are typically coarse (without a specific correct value) and usually meant to catch deadlocks. Side note: to support the deadline use case, all timed operations have to include an overload taking an absolute value.
An additional relative timeout overload in the cases where it's appropriate could work, but the current templatization does not allow it unless concepts come into play.
Well, where would it not be appropriate?
I think that the non-predicate version of condition::timed_wait should not allow a relative timeout since this would make it even more error-prone than it is now.
"Peter Dimov" <pdimov@pdimov.com> skrev i meddelandet news:010601c811a7$df700410$6407a80a@pdimov2...
Johan Nilsson:
I believe there are "relative" deadlines as well. Suppose you are receiving data that should arrive at a certain frequency; if that frequency is e.g. 20Hz, a reasonable value for emitting a data timeout warning could be 2 periods => 50*2 = 100ms (in this case, a background thread would put each data item in a common buffer when it arrives, and signal the cv for some other entity to process it).
You may well start out with a relative timeout value, but it's converted to an absolute deadline just once, at the start, on a high level that doesn't usually deal with thread primitives. Then you propagate the absolute deadline through code. Something like:
bool f( abstime const & dl ) { return g( dl ) && h( dl ); }
(guaranteed wait-free rollback on failed h omitted for simplicity :-) ).
Even for the simple condvar wait case, you have a preceding mutex lock which needs to also respect the deadline.
So the decision to use absolute times are due to implementation details? Ok, sounds reasonable. The problem for me with having absolute times in the interface is that it does not show my (the programmer's) intent to wait for a relative time. On the other hand, having relative times in the interface while using absolute times in the implementation is sort of like lying to the clients, as it actually changes the semantics a bit ... (just thinking out loud). What would be really nice to have would be something like a high-res std::monotonic_time (assuming proper platform support).
Relative timeouts on the primitive level are typically coarse (without a specific correct value) and usually meant to catch deadlocks.
Does "on the primitive level" mean deep within the thread library code?
Side note: to support the deadline use case, all timed operations have to include an overload taking an absolute value.
An additional relative timeout overload in the cases where it's appropriate could work, but the current templatization does not allow it unless concepts come into play.
Well, where would it not be appropriate?
I think that the non-predicate version of condition::timed_wait should not allow a relative timeout since this would make it even more error-prone than it is now.
Of course. I've been almost excusively been using the predicate-based version myself, so I didn't reflect on the problems when using timed_wait within the context of a loop. Until now, that is. As a side note: I actually took the time to read through n2320, modulo the reference part. A really great job, which actually made me smile at some point (first time ever when reading this kind of document)! Pretty much the only thing that I could complain about (and this was only a minor annoyance) was the usage of the "this_thread" namespace. I recognize the analogy to "this", but "current_thread" was the first name that came to mind (implemented as a class with static members instead of a namespace). I guess "this" is less ambiguous than "current", but the latter feels like a more natural alternative. Perhaps this is just my Win32 heritage. / Johan
Johan Nilsson:
"Peter Dimov" <pdimov@pdimov.com> skrev i meddelandet news:010601c811a7$df700410$6407a80a@pdimov2...
bool f( abstime const & dl ) { return g( dl ) && h( dl ); }
(guaranteed wait-free rollback on failed h omitted for simplicity :-) ).
Even for the simple condvar wait case, you have a preceding mutex lock which needs to also respect the deadline.
So the decision to use absolute times are due to implementation details? Ok, sounds reasonable.
No. It has nothing to do with implementation details. f is a user function, not a Boost.Threads function. The point is that absolute timeouts are composable, and relative timeouts are not. Consider: bool f( abstime const & dl ) { if( !m1.timed_lock( dl ) ) return false; if( !m2.timed_lock( dl ) ) return false; // do something with the data protected by m1 and m2 } (RAII omitted for brevity.) Rewrite this with a relative timeout timed_lock and you'll see what I mean. The same principle applies to every function which needs to perform more than one time-consuming or potentially blocking operation. bool f2( abstime const & dl ) { if( !m1.timed_lock( dl ) ) return false; if( !cn.timed_wait( m1, dl, pred() ) ) return false; // do something } bool timed_lock( timed_mutex & m1, timed_mutex & m2, abstime const & dl ) { for( ;; ) { if( !m1.timed_lock( dl ) ) return false; if( m2.try_lock() ) return true; m1.unlock(); if( !m2.timed_lock( dl ) ) return false; if( m1.try_lock() ) return true; m2.unlock(); } }
Peter Dimov wrote:
Johan Nilsson:
"Peter Dimov" <pdimov@pdimov.com> skrev i meddelandet news:010601c811a7$df700410$6407a80a@pdimov2...
bool f( abstime const & dl ) { return g( dl ) && h( dl ); }
(guaranteed wait-free rollback on failed h omitted for simplicity :-) ).
Even for the simple condvar wait case, you have a preceding mutex lock which needs to also respect the deadline.
So the decision to use absolute times are due to implementation details? Ok, sounds reasonable.
No. It has nothing to do with implementation details. f is a user function, not a Boost.Threads function. The point is that absolute timeouts are composable, and relative timeouts are not.
I understand that. What I meant to say was that to be able to support certain constructs uniformly for multiple platforms, one is forced to use absolute times (composition being one of these constructs). If something similar to WaitForMultipleObjects were universally available the absolute times might not be neccesary, no matter what Butenhof says. Sorry for being unclear and wasting your time. (and there was no sarcasm intended in the "sounds reasonable" part above) / Johan
catching up with a couple messages: Johan Nilsson wrote:
n2320 calls for interfaces with time_duration on all timed_lock functions.
What about sleep?
There is a relative time sleep function: namespace std { namespace this_thread { template <class ElapsedTime> void sleep(const ElapsedTime& rel_t); } } Peter Dimov wrote:
Johan Nilsson wrote:
Peter Dimov wrote:
Johan Nilsson wrote:
It's possible to handle spurious wakeups with relative times as well, perhaps just not perfectly (depending on underlying platform support). If the only way to perform a timed wait on a condition variable is by an absolute time, I believe the most common usage will be something like this (pseudocode):
--- time now = microsec_clock::local_time(); time timeout = now + milliseconds(250); if (!cv.timed_wait(lk, timeout, my_pred())) { throw "Timed out!"; } You are missing a loop. I think you're missing the predicate "my_pred()".
You are right, I was. Relative timeouts do indeed make sense for the predicate version, if (1) you are willing to accept the inconsistency and (2) you are only concerned with use cases like the above where the timeout is not a deadline but a safety net.
An additional relative timeout overload in the cases where it's appropriate could work, but the current templatization does not allow it unless concepts come into play.
n2320 proposal includes both relative and absolute timeouts for the condition variables. As you can imagine, if the client writes the loop, instead of using the predicate form, having an absolute time overload simplifies the code. There's another subtle issue as well. You want to use the same clock implementation for measuring these...which is part of the justification for system_time. Jeff
Jeff Garland wrote:
n2320 proposal includes both relative and absolute timeouts for the condition variables.
It does? I only see bool timed_wait(lock_type& lock, const utc_time& abs_time); template <class Predicate> bool timed_wait(lock_type& lock, const utc_time& abs_time, Predicate pred); in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2320.html#Condition... and N2406 follows suit: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406.html#cond_var_...
Peter Dimov wrote:
Jeff Garland wrote:
n2320 proposal includes both relative and absolute timeouts for the condition variables.
It does? I only see
bool timed_wait(lock_type& lock, const utc_time& abs_time); template <class Predicate> bool timed_wait(lock_type& lock, const utc_time& abs_time, Predicate pred);
in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2320.html#Condition...
and N2406 follows suit:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406.html#cond_var_...
I stand correct -- I think it was 'supposed to' ;-) Sorry, I've seen various revisions of this paper some of which in my recollection had relative time interfaces. So let me say it another way: I believe a relative time interface should be offered here in addition to the absolute time. So I'm not sure what happened there -- Howard may have talked me out of it somehow or maybe it was accidentally dropped... Jeff
On Oct 18, 2007, at 10:46 AM, Jeff Garland wrote:
Peter Dimov wrote:
Jeff Garland wrote:
n2320 proposal includes both relative and absolute timeouts for the condition variables.
It does? I only see
bool timed_wait(lock_type& lock, const utc_time& abs_time); template <class Predicate> bool timed_wait(lock_type& lock, const utc_time& abs_time, Predicate pred);
in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2320.html#Condition...
and N2406 follows suit:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406.html#cond_var_...
I stand correct -- I think it was 'supposed to' ;-) Sorry, I've seen various revisions of this paper some of which in my recollection had relative time interfaces. So let me say it another way: I believe a relative time interface should be offered here in addition to the absolute time. So I'm not sure what happened there -- Howard may have talked me out of it somehow or maybe it was accidentally dropped...
I haven't written a paper with a relative time on the predicate version of cv::timed_wait, but I have no objection to such an overload if it can be done (with concepts or enable_if or whatever) -- on the predicate version only. This might be considered a semantic difference so may require a separate paper. -Howard
Hello What could be used instead of boost::thread::detail::lock_ops? It used by threadpool library, that i want to adopt to new boost.thread -- With best wishes, Alex Ott, MBA http://alexott.blogspot.com/ http://alexott-ru.blogspot.com/ http://content-filtering.blogspot.com/ http://xtalk.msk.su/~ott/
"Alex Ott" <alexott@gmail.com> writes:
What could be used instead of boost::thread::detail::lock_ops? It used by threadpool library, that i want to adopt to new boost.thread
The new mutexes just have simple lock/unlock members, so lock_ops is no longer needed. Anthony -- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
Ok, thanks I think, that you need to delete it from svn to avoid misunderstanding On 10/16/07, Anthony Williams <anthony_w.geo@yahoo.com> wrote:
"Alex Ott" <alexott@gmail.com> writes:
What could be used instead of boost::thread::detail::lock_ops? It used by threadpool library, that i want to adopt to new boost.thread
The new mutexes just have simple lock/unlock members, so lock_ops is no longer needed.
Anthony -- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- With best wishes, Alex Ott, MBA http://alexott.blogspot.com/ http://alexott-ru.blogspot.com/ http://content-filtering.blogspot.com/ http://xtalk.msk.su/~ott/
"Alex Ott" <alexott@gmail.com> writes:
I think, that you need to delete it from svn to avoid misunderstanding
I have now removed thread/detail/lock.hpp from SVN as no longer needed. Anthony -- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
"Sean Huang" <huangsean@hotmail.com> writes:
1. Do changes in this magnitude warrant a mini-review?
If anyone wants to review my code, I welcome their input. Anthony -- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
on Sun Oct 14 2007, "Sean Huang" <huangsean-AT-hotmail.com> wrote:
Specifically, my questions are: 1. Do changes in this magnitude warrant a mini-review? 2. Is it a good idea that the new implementation be reviewed by other boost threading experts such as Peter and/or Howard? Take it to the next level, does it make sense to have a peer review process for at least significant changes?
It's a good idea, but I don't think we should mandate it. The autonomy of library developers to make improvements has always been a core Boost policy, and taking that away could significantly dampen the sense of ownership (and thus enthusiasm) of library authors. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
on Sun Oct 14 2007, "Sean Huang" <huangsean-AT-hotmail.com> wrote:
Specifically, my questions are: 1. Do changes in this magnitude warrant a mini-review? 2. Is it a good idea that the new implementation be reviewed by other boost threading experts such as Peter and/or Howard? Take it to the next level, does it make sense to have a peer review process for at least significant changes?
It's a good idea, but I don't think we should mandate it. The autonomy of library developers to make improvements has always been a core Boost policy, and taking that away could significantly dampen the sense of ownership (and thus enthusiasm) of library authors.
I agree with Dave. The thread library (and some other Boost libs) are also a bit special in that they are becoming (or already have become) part of the C++ standard library. That is subjecting them to a whole additional level of peer review, including an upcoming public review period. --Beman
participants (10)
-
Alex Ott -
Anthony Williams -
Beman Dawes -
David Abrahams -
gchen -
Howard Hinnant -
Jeff Garland -
Johan Nilsson -
Peter Dimov -
Sean Huang