- Boost - lists.boost.org

Re: Boost.Threads proposed change: lock constructors
by Batov, Vladimir 28 Jun '04

28 Jun '04

> Part of the point, though, is that try_lock doesn't actually work that > way: one of the try_lock constructors does a non-blocking try_lock(), > and the other does a blocking lock(). Without looking, do you always > remember which one does which? I don't. Well, first, the behavior that I was talking about in my prev. email (ones I was happy about) were the 'basic' constructors (that I called 'default' constructors -- what an embarassment). The following is IMHO good and I would not like see them complicated: 1. scoped_lock l(m); // Blocks until it locks. 2. scoped_lock l(m, true); // As above. 3. scoped_lock l(m, false); // Only declaration. Does nothing. Needed if I need to declare but use it later. 4. try_lock l(m); // Tries to lock. Always falls through. I need to check the result. 5. try_lock l(m, false); // Only declaration. Does nothing. 6. timed_lock l(m, time); // Blocks until locks or 'time' expires. 7. timed_lock l(m, false); // Only declaration. Does nothing. I have to agree that the following behavior 8. try_lock l(m, true); 9. timed_lock l(m, true); that according to the documentation call lock() instead of respective try_lock() and timed_lock() look wrong. I'd be temted to say that merely making (8) work as (4) would be sufficient fo fix try_lock. (9) does not appear "fixable" in a similar way. I am tempted to suggest something similar to overloaded 'operator new': struct nolock_t {}; nolock_t nolock; 1. scoped_lock l(m); 2. scoped_lock l(m, nolock); 3. try_lock l(m); 4. try_lock l(m, nolock); 5. timed_lock l(m, time); 6. timed_lock l(m, nolock); It removes redundancy (as with the original scoped_lock(m) and scoped_lock(m, true)) and makes everything simple and consistent. Just a thought. V

2 1

How to handle name mangling in "versioned" toolsets?
by John Maddock 28 Jun '04

28 Jun '04

At present we have two types of toolsets: 1) Unversioned toolsets such as "intel-win32", which produce unversioned toolset suffixes to library names, "iw" in this case. 2) Versioned toolsets such as "intel-win32-7.1-vc6-stlport-4.5.3" which produce versioned toolset suffixes to library names, "iw71" in this case. This produces a problem with the autolinking code which can take either approach, but not both (or at least not both auto-magically, and this is causing some regression test failures at present). In other words I'm asking for some kind of consistent policy here; note that if the choice is to consistently use "versioned" toolsets then we're committing ourselves to constantly updating the build system and autolinking code to keep up with new compiler releases. So, I guess I'm leaning towards "unversioned" mangled toolset names, but would like more some feedback, so: what does everyone else think? Thanks, John.

3 2

Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 28 Jun '04

28 Jun '04

My question was more about the design rather than how I could work it around. I may be wrong but specializing mutex does not look like a good idea as it appears to be lock-specific functionality. So, I thought we might consider having only mutex and typedefing others to it (not to break old code) -- the simpler the better. Isn't it? V. > Do we need all three separate concepts -- mutex, try_mutex and > timed_mutex? I think the idea was that it would be possible to implement the mutex types that supported fewer operations more efficiently. Whether this actually turned out to be true is another question. > I'd expect the mutex concept to remain unchanged and "try" > and "timed" refinements to be related solely to the ways I try locking > that only mutex. That is, I always have one mutex and under different > circumstances lock it unconditionally (scoped_lock) or try locking it > and check if that attempt succeeds (scoped_try_lock) or try locking > within a certain time period (scoped_timed_lock). If you want this, just use a timed_mutex and scoped_timed_lock. In the current release it supports lock() and timed_lock() operations; in the next release it will support try_lock() as well. Mike ------------------------------ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost End of Boost Digest, Vol 772, Issue 2 *************************************

1 0

GCC 3.4 lpthread warnings
by Jeff Garland 28 Jun '04

28 Jun '04

On the regression tests I'm seeing lots of warnings from gcc 3.4. For example: date_time - test_greg_wstream - gcc-3.4.0-linux Compiler output: In file included from /boost/head-regression/boost/boost/config.hpp:44, from /boost/head-regression/boost/boost/date_time/locale_config.hpp:19, from /boost/head-regression/boost/boost/date_time/compiler_config.hpp:14, from /boost/head-regression/boost/boost/date_time/gregorian/gregorian.hpp:19, from ../libs/date_time/test/gregorian/testgreg_wstream.cpp:10: /boost/head-regression/boost/boost/config/stdlib/libstdcpp3.hpp:33:7: warning: #warning "Boost threading support turned on, you may need to link against -lpthread unless you define BOOST_DISABLE_THREADS when building." Lots of other libraries are seeing similar warnings with gcc 3.4. Date-time does nothing with threads so I believe based that I should just set define BOOST_DISABLE_THREADS for the test cases to resolve this. But since I'm not certain of all the implications of this I thought I'd as for advice before proceeding. One specific question that comes to mind is do I need to limit the scope to gcc so I don't break MT, dll mode on Windows? Thanks, Jeff

6 15

[admin] Wiki Spam -- IP's are being banned
by Jeff Garland 28 Jun '04

28 Jun '04

All - I'm cross-posting this to boost-users and the developer list since it pertains to both. Over the last couple months there has been a rise in 'spam attacks' on the Wiki. Basically people are inserting links to commercial sites on wiki pages. These sites are totally unrelated to boost, c++, etc. I thank the many boosters that have spent their precious time removing the defacements. But the time has come to crack down. The following IP ranges have been banned from the Wiki. 61.55.32.* 61.55.33.* 69.63.103.* 210.82.76.* 210.82.106.* 219.233.195.* 218.5.65.* I will be monitoring and banning additional IP addresses as needed. If I have accidentally banned someone incorrectly, please let me know offlist: jeff at crystalclearsoftware.com Thanks, Jeff

1 0

shared_ptr<> and atomic_count
by Colin Rafferty 28 Jun '04

28 Jun '04

Hi- Looking at the implementation of shared_count<>, it seems as though it always uses a mutex for incrementing and decrementing the counter. Is there a reason why we aren't using atomic_count instead? In the worst case, it will have the same performance, but in the best case, it can be significantly faster (BOOST_USE_ASM_ATOMIC_H). Thanks. -- Colin Rafferty

1 0

Re: 1.32 release preparation
by Johannes Brunen 28 Jun '04

28 Jun '04

On Mon, 28 Jun 2004 07:37:24 -0400, David Abrahams wrote > Boost.Graph changes have caused plenty of regressions in Boost.Python > in the past. Sorry, I thougth that this would be a pretty good example of a high level library. So I was wrong. On Mon, 28 Jun 2004 07:33:26 -0400, David Abrahams wrote > We should have more releases. Waiting for libraries to be checked in > is one thing that keeps us from being able to release more frequently. Yes, but if I have the choice of waiting one additional week for the check in of an accepted library against waiting 2 month for the next release I would choose to wait that additional week. However, I have read in one of the other mails that you have a deadline with your book. So live is not that simple at all. I won't persist on changing the planned schedule. Don't get me wrong. > It sounds like you want a whole new Boost procedure for reviews *and* > releases. That seems like a stretch; we don't have any idea whether > it would work at all. No, I merely think that a library should be accepted when it is ready for checkin and there is not a list of changes and request pending. On Mon, 28 Jun 2004 07:34:22 -0400, David Abrahams wrote >> On Mon, 28 Jun 2004 10:51:36 +0200, Johannes Brunen wrotes >> We should list them on the lib page but in a special section. > I don't like the sound of that. It should be very clear to people > which things are part of Boost and which aren't. Ok, I second that. If it not clear for people what is part of boost then it is the wrong way. People should be able to build on a boost release. With kind regards Johannes

1 0

iterator_traits.pdf not marked as binary
by Peter Dimov 28 Jun '04

28 Jun '04

libs/iterator/doc/iterator_traits.pdf is not marked as binary in the CVS. -- Peter Dimov http://www.pdimov.com

2 1

[Graph] What to do about broken compilers?
by Doug Gregor 28 Jun '04

28 Jun '04

The graph library has always been in a "barely usable" support on certain compilers (Borland <= 5.6.4 and MSVC 6.0, in particular). The regression tests have always been a mess---Boost 1.31.0 has very few passes for these compilers, and 1.32.0 isn't looking any better. However, the library is somewhat usable, if you stick to a very small subset and don't mind working around INTERNAL COMPILER ERRORs all of the time. What to do? I'm marking the library "unusable" on both compilers, so that we can concentrate our efforts on those compilers that might actually work. Complain loudly, quickly, and preferably with patches if you think this is the wrong approach. Doug

4 5

Boost.Threads: RW mutexes and locks.
by Batov, Vladimir 28 Jun '04

28 Jun '04

RW mutexes/locks are important to a threading library and appear simple to implement. However, Boost.Threads lacks it. I wrote something simple that appear to do the job using the functionality already available in Boost.Threads. If the idea is considered good/robust/efficient enough and worth having in the library, I can re-write it to conform with the rest of Boost.Threads. class rw_mutex : private boost::noncopyable { typedef boost::condition Condition; public: friend class writer_lock; friend class reader_lock; rw_mutex() : num_readers_(0), num_writers_(0) {} private: boost::mutex mutex_; Condition reader_condition_; Condition writer_condition_; int num_readers_; int num_writers_; }; class writer_lock : public boost::mutex::scoped_lock { typedef boost::mutex::scoped_lock super; public: writer_lock(rw_mutex& mutex) : super(mutex.mutex_), mutex_(mutex) { ++mutex_.num_writers_; // Make new readers wait. // If there are readers in-progress, wait for them to finish. while (mutex_.num_readers_) mutex_.writer_condition_.wait(*this); } ~writer_lock() { --mutex_.num_writers_; // Last writer notifies waiting readers. // If not last, wake up the next writer. if (!mutex_.num_writers_) mutex_.reader_condition_.notify_all(); else mutex_.writer_condition_.notify_one(); } private: rw_mutex& mutex_; }; class reader_lock : public boost::mutex::scoped_lock { typedef boost::mutex::scoped_lock super; public: reader_lock(rw_mutex& mutex) : super(mutex.mutex_), mutex_(mutex) { // If there are writers waiting, let them in first. while (mutex_.num_writers_) mutex_.reader_condition_.wait(*this); ++mutex_.num_readers_; // Make new writes wait. unlock(); } ~reader_lock() { lock(); --mutex_.num_readers_; // Last reader notifies if (!mutex_.num_readers_) mutex_.writer_condition_.notify_one(); } private: rw_mutex& mutex_; };

3 2