- Boost - lists.boost.org

Question about stdlib in gcc-2.95.3-linux toolset
by Joaquín Mª López Muñoz 06 Jul '04

06 Jul '04

A test of mine is failing in the gcc-2.95.3-linux toolset with the following: ostream: No such file or directory which, I guess, indicates that the std library used by this toolset does not have a <ostream> header. Digging through the regression logs, seems like the library being used is SGI's. Now, there is not defect macro in config/stdlib/sgi.hpp indicating that <ostream> is not available, so my question is: * Is this defect in gcc 2.95 known, and not an installation artifact? * If so, is there any way to figure it out from Boost.Config defect macros or some combination of these and SGI-specific macros? Maybe I'm missing something obvious and this lack of standard headers by gcc 2.95 is common knowledge, I just happen not to have dealt with this compiler ever. Thanks Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

Does anyone have an is_virtual_base_and_derived ?
by Robert Ramey 06 Jul '04

06 Jul '04

Type traits includes: ::boost::is_base_and_derived<T,U> Does anyone have a version that might be called is_virtual_base_and_derived<B, D> which would return true iff D is derived virtually from B ? Robert Ramey

1 0

Re: [utility] boost::reset
by jhopkin＠reflectionsinteractive.com 06 Jul '04

06 Jul '04

Daniel Frey wrote: > > Gennaro Prota wrote: > > > Does the swap trick necessarily free the memory? > > AFAIK, yes. See <http://www.gotw.ca/gotw/054.htm>. > The STL implementation I have been using seems to allocate a buffer on first insertion into any container of a given type, and frees it only when it feels like it (often on program shut-down). I don't know if it's a strictly conforming implementation in that respect, although I can't see anything in the standard prohibiting this behaviour. James Hopkin

3 2

Re: Boost Mathematicians
by Michael Stevens 06 Jul '04

06 Jul '04

On Monday 05 July 2004 22:59, David Abrahams <dave(a)boost-consulting.com> wrote: > > Almost all the major reference works on BLAS and Matrices > > simply state elements are either Real or Complex and are therefore > > implicitly a field. > > We're not just concerned about the elements of matrices, but the > vectors and matrices themselves. OK I was assuming you were looking for a clear concept definition for the element types. > This becomes a real issue when you > have to write algorithms that might operate on matrices of reals or > matrices of matrices -- yes, these things do come up in real > applications. This is very odd. In linear algebra there is no such thing as a matrix of matrices. This impacts on the while prod/operator* controversy. That is, the primary advantage of not defining operator*. It prevents you passing matrix to an algorithm (not necessarily part of the uBLAS itself) that uses operator* and not unreasonably makes the assumption that operator* is commutative. The assumption is not unreasonable as all built in types operator* is exactly commutative. That said I have also argued in favour of operator* instead of prod in the past. It's central role in LA certainly argues in favour of using operator*. This involves so much peoples expectation as for algebraic notation, programming practice and just personal taste. > >> * Redundant specification of element type in matrix/vector storage. > > See my reply to Toon. Ah yes value_type is specified in both the matrix vector and storage type parameter list. In itself this is not good as the storage type should parameterise the matrix/vector with the value_type. It is simply there to make the syntax in the default case simple without the need for a type generator as in MTL. > > For std::slice (valarray) compatibility stride should be last. Not sure why > > this was not picked up on a long time ago!! > > valarray (and uBLAS) use size (not end) for good reason however. > > ...which is...? The begin end definition fails when stride==0. Slices of finite size with stride==0 are very useful. Similarly when (end-begin) *stride <0 the behaviour would have to be defined. > > Interesting solution. Agreed, the current implementation is closed to other > > objects because of the intrusive base class. Sadly uBLAS was designed before > > enable_if. Any pointers to compile/runtime effects of the enable_if solution? > > I can't really imagine what you're asking for here. I was looking for any publications/links to compare how compilers do between the two solutions. Anyone have any pointers? Thanks, Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

4 5

[utility] boost::reset
by Daniel Frey 06 Jul '04

06 Jul '04

Hi, I just wrote a small helper function to clear a container. Well, OK, we already have that, do we? For a container 'cont': cont.clear(); But this doesn't neccessarily free the memory allocated. The "usual" workaround is: Cont().swap( cont ); But Cont (the type of the container) is sometimes rather large and the code doesn't communicate well what I intended. I thus wrote the following small helper: template< typename T > void reset( T& t ) { T().swap( t ); } Would this make a good addition to boost.utility? Any comments welcome... Regards, Daniel -- Daniel Frey aixigo AG - financial solutions & technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: daniel.frey(a)aixigo.de, web: http://www.aixigo.de

5 13

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Glen Knowles 06 Jul '04

06 Jul '04

> From: Howard Hinnant > > Exploring the case: throw exception if unable to atomically > promote read to write: > > If an exception is not thrown, then you are guaranteed what > you previously read is still true, and all is well. If an > exception is thrown, then you have to re-read to determine > current state. First, to be clear, a promote() _must_ not be allowed to silently fail, otherwise you break the contract and people will spend several days tracking down the problem. If you want that behavior you should use try_promote(). I don't have a problem with it simply deadlocking, or, if that's unacceptable don't have the blocking promote() function. The complexity involved in determining a deadlock may be well beyond what you want to do at this level in the library, I'll come back to this later. But for now, lets talk about throwing. In my mind the purpose of throwing is to allow the other thread (or threads, with the database work I've been doing multiple read locks on an object all trying to be promoted to write locks at the same time happens more often then you might think) to proceed, which it can't do unless you give up your _read_ lock. > > Hmm... > > Given that when you have write privilege you also implicitly > have read privilege, this seems a little extreme. Would it > not be both more efficient and easier to follow if you just > reaffirm your state under the write lock rather than assume > your state, and write a catch block to reassert it if it > happens to be false? That is, this: > > bool try_sale(rw_mutex& m) > { > read_lock rl(m); > > long balance = get_balance(); > long cost = get_total_cost(); > > if (balance > cost) > { > write_lock wl(rl); > set_balance(balance - cost); > // ... > return true; > } > return false > } > > bool do_sale(rw_mutex& m) > { > while (true) > { > try_again: > try { > return try_sale(m); > catch (rw_promotion_error&) { > // Try the whole thing again > // how is this implemented? > goto try_again; // ? > } > } > } > > vs this: > > void do_sale(rw_mutex& m) > { > read_lock rl(m); > > long balance = get_balance(); > long cost = get_total_cost(); > > if (balance > cost) > { > rl.unlock(m); > write_lock wl(m); > set_balance(balance - cost); > wl.transfer_to_read_lock(rl); > balance = get_balance(); > } > // ... > } > > My assertion is that you don't know a-priori if the > read-to-write promotion achieves anything or not. If you > allow it to fail, by exception, or by error code, or by any > other means, then you have to write code to re-read the > current state. If you don't allow it to fail, then you must > make it block until it succeeds. The latter seems simpler in > logic, and smaller in code size. The logic is quite simple: > > read_lock to write_lock promotion is not atomic. > > Once that is understood, the programmer can just deal with > it. Trying to encapsulate this bit of reality only serves to > obfuscate the necessary logic. The reason that "release read, acquire write" appears a complete alternative to promotion is because your example is too simple. You may need the read lock to keep the object alive in a cache, where it could be flushed to disk and destroyed if you release it, forcing you to re-read it before getting your write lock. I think that the library should either commit to detecting deadlocks or don't do it at all. Is it going to throw a promotion exception in this case? Thread A: read lock x Thread A: read lock y Thread B: read lock y Thread B: write lock x, blocks Thread A: promote y to write lock, blocks In order to detect things like this you essentially need to build a complete conflict matrix of all held locks in the system, and if you do that I assume you'd also use it to detect deadlocks of regular locks: Thread A: lock x Thread B: lock y Thread A: lock y, blocks Thread B: lock x, blocks Glen

2 1

Re: Boost Mathematicians
by Michael Stevens 06 Jul '04

06 Jul '04

On Tuesday 06 July 2004 01:30, "Aleksey Gurtovoy" <agurtovoy(a)meta-comm.com> wrote: > Neither 'size1' nor 'num_rows' are generic, though. What you want is > something like > > template< int n > size(int_<n>); > > The particular int_<n> specializations then can be typedef'ed to > something more mnemonic, e.g. > > typedef int_<0> rows; > > or even > > extern int_<0> rows; > > The lack of this genericity will force you, sooner or later, to resort > to code duplication. I believe Vesa made the same point a long time > ago... yep: http://thread.gmane.org/gmane.comp.lib.boost.devel/60338. Aleksey, Thanks for point this out. I had forgotten about Vesa contribution. It seems this is very much a repeat of the discussion you link to. Interestingly uBLAS never did get the generic versions of the functions. Although it gained a set of similar functions for major/minor mappings. Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

1 0

Re: Lightweight Mutex Code
by Tyson Whitehead 06 Jul '04

06 Jul '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron W. LaFramboise wrote: > I am not sure what the status of these are. Are other components > supposed to be using these? I came upon them when I was checking out the smart pointers implementation. Grepping the source seems to indicate 'lightweight_mutex.hpp' is only used by the smart pointers (only included by 'quick_allocator.hpp' and 'shared_count.hpp') under multithreaded conditions. > In addition to what you mentioned, they're broken in other ways: > > If a low priority thread is preempted by a high priority thread > immediately before __atomic_add, and the high priority thread is > attempting to grab the spinlock, deadlock is acheived, despite the > sched_yield(). I missed that one. You're right though, and not only that, but the sched_yield manpage states (I'm assuming this applies to threads -- threads in Linux are actually processes -- right?): "Note: If the current process is the only process in the highest priority list at that time, this process will continue to run after a call to sched_yield." The implementer seemed to be aware there could be priority problems though. The relevant comments in 'lightweight_mutex.hpp' are: // * Used by the smart pointer library // * Performance oriented // * Header-only implementation // * Small memory footprint // * Not a general purpose mutex, use boost::mutex, CRITICAL_SECTION or // pthread_mutex instead. // * Never spin in a tight lock/do-something/unlock loop, since // lightweight_mutex does not guarantee fairness. // * Never keep a lightweight_mutex locked for long periods. // // The current implementation can use a pthread_mutex, a CRITICAL_SECTION, // or a platform-specific spinlock. // // You can force a particular implementation by defining // BOOST_LWM_USE_PTHREADS, // BOOST_LWM_USE_CRITICAL_SECTION, or // BOOST_LWM_USE_SPINLOCK. // // If neither macro has been defined, the default is to use a spinlock on // Win32, and a pthread_mutex otherwise. // // Note that a spinlock is not a general synchronization primitive. In // particular, it is not guaranteed to be a memory barrier, and it is // possible to "livelock" if a lower-priority thread has acquired the // spinlock but a higher-priority thread is spinning trying to acquire the // same lock. // // For these reasons, spinlocks have been disabled by default except on // Windows, where a spinlock can be several orders of magnitude faster than a // CRITICAL_SECTION. The current Win32 doesn't have the counter problems, and claims to be able to yield to lower priority threads, so it should be okay. The relevant lock routine is (m_.l_ is initialized to 0): while( InterlockedExchange(&m_.l_, 1) ){ // Note: changed to Sleep(1) from Sleep(0). // According to MSDN, Sleep(0) will never yield // to a lower-priority thread, whereas Sleep(1) // will. Performance seems not to be affected. Sleep(1); } The unlock routine is: InterlockedExchange(&m_.l_, 0); - -T - -- Tyson Whitehead (-twhitehe(a)uwo.ca -- WSC-) Computer Engineer Dept. of Applied Mathematics, Graduate Student- Applied Mathematics University of Western Ontario, GnuPG Key ID# 0x8A2AB5D8 London, Ontario, Canada -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA6a+FRXbLmIoqtdgRAqxRAJ0RxqXlsbc5i5GBCydxFWgqTU32sQCgyJ/Y py3rSxTj5BiVUmXPqoP/zcY= =nVLD -----END PGP SIGNATURE-----

5 8

Lightweight Mutex Code
by Tyson Whitehead 06 Jul '04

06 Jul '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I believe there is a mistake in the 'details/lwm_gcc.hpp' and 'details/lwm_linux.hpp' (and possibly the other lightweight_mutex implementation as well -- I haven't looked at them). In both of these files we have a counter (m_.a_) that is initialized to 1. The lock routine is implemented as follows: while( !__exchange_and_add(&m_.a_, -1) ){ __atomic_add(&m_.a_, 1); sched_yield(); } The unlock as: __atomic_add(&m_.a_, 1); This works if there are only two contenders for the lock. It can fail if there are three or more: 1- Thread one takes the lock, putting the counter at 0. 2- Thread two does the __exchange_and_add, fails the test, and then its time time slice expires before the __atomic_add, leaving the counter at -1. 3- Thread three also takes the lock (because !-1 is false). A simple solution is to initialize the counter to zero and replace the above lock by: while( __exchange_and_add(&m_.a_, 1) ){ __atomic_add(&m_.a_, -1); sched_yield(); } and the unlock by: __atomic_add(&m_.a_, -1); This would result in: 1- Thread one takes the lock, putting the counter at 1. 2- Thread two does the __exchange_and_add, fails the test, and then its time slice expires before it can do the __atomic_add, leaving the counter at 2. 3- Thread cannot take the the lock (because 2 is true). - -T - -- Tyson Whitehead (-twhitehe(a)uwo.ca -- WSC-) Computer Engineer Dept. of Applied Mathematics, Graduate Student- Applied Mathematics University of Western Ontario, GnuPG Key ID# 0x8A2AB5D8 London, Ontario, Canada -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA5dgwRXbLmIoqtdgRAmbyAJ0aZFZvxn5MXeXyNqSAI63o9EqddQCfTK9p wFAoBbQueoo9hLNhXJtit44= =SPra -----END PGP SIGNATURE-----

3 2

Re:Re: [boost] Re: 1.32 release preparation
by Robert Ramey 06 Jul '04

06 Jul '04

Message: 16 Date: Sun, 27 Jun 2004 22:25:47 -0500 From: "Aaron W. LaFramboise" <aaronrabiddog51(a)aaronwl.com> Subject: Re: [boost] Re: 1.32 release preparation To: boost(a)lists.boost.org Message-ID: <40DF8FBB.4040408(a)aaronwl.com> Content-Type: text/plain; charset=us-ascii Aaron W. LaFramboise wrote: >Robert Ramey wrote: >> Dave Abrahams wrote: >> >> >>>I'd like to know the reasons for "all the sudden rush". We did >>>announce a schedule long ago, and it has already been delayed by three >>>weeks. I'm not asking in order to point fingers; I just want to know >>>how to avoid the "sudden rush" next time. >> >> >> Here is the current scenario. >> >> a) The announcement gets posted - release 1.32 scheduled for date x. >> b) Each developer decides - uh oh I better get in my changes before date x. >> c) Of course these changes take longer >> d) and break some other things >> e) which takes longer still >> >> Personally I think the concept of scheduling a release fundamentally flawed. >> I would suggest another idea. >As an observer, I'm fairly impressed with GCC's release methodology. >http://gcc.gnu.org/develop.html >A critical component is a schedule that includes several stages during >which certain sorts of changes are unacceptable. >There's still rush, but most of the rush for major features or other >destabilizing elements happens long before the release comes around. I found this to be very interesting. I had never seen this before. It basically implements my view that the "Main Line" should be code that is always works and is ready to be used, tested and potentially released. As far as I'm concerned it's totally consistent with my proposal which I thought was un-orthodox but now see that is used at least by GCC. So, my view would be - stick to the original 28 June date, require that new libraries be added to branches and merge to main as appropriate. I realize its not THAT easy - but it would address the concerns that I have about the whole process and allow all libraries to proceed on independent schedules. New libraries would be tested against the "known good tree" independently of one another. Take as a small example changes in MPL. The current method is to check in a new version of MPL and see what happens. Presumable some issues will arise and now we have a broken system which inhibits development of other libraries until the issues are resolved. Under the proposed method, the new MPL would be check in under its own branch and issues would be detected on all libraries before they affect other developers. Anyway - my 2 cents. Robert Ramey

8 16