- Boost - lists.boost.org

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

boot::mpl::list problem
by zaufi 06 Jul '04

06 Jul '04

Hi all! I have a problem compiling the following simple program without defining BOOST_MPL_NO_PREPROCESSED_HEADERS. Though obviously there are preprocessed headers in boost/mpl/list/aux_/preprocessed/plain. The problem seems to be in compiler-specific preprocessed header (for example boost/mpl/aux_/preprocessed/gcc/list.hpp) where list is defined with 10 arguments regardless of BOOST_MPL_LIMIT_LIST_SIZE value. ---{boost_list.cc} --------------------------------------------- // # define BOOST_MPL_NO_PREPROCESSED_HEADERS # if !defined(BOOST_MPL_LIMIT_LIST_SIZE) || (BOOST_MPL_LIMIT_LIST_SIZE < 20) # undef BOOST_MPL_LIMIT_LIST_SIZE # define BOOST_MPL_LIMIT_LIST_SIZE 20 # endif #include <boost/mpl/list.hpp> typedef boost::mpl::list< int, int, int, int, int , int, int, int, int, int , int, int, int, int, int > my_list; int main() { my_list l; return 0; }; ---------------------------------------{end of boost_list.cc}--- any suggestions?? regards. zaufi.

2 1

Boost.Test, failed assert output
by Glen Knowles 06 Jul '04

06 Jul '04

This is my first time using Boost.Test. I was able to get started pretty quickly from the docs, and I'd like to start by saying that the library looks pretty good. Now for my request. ;) I'm using vc++ 7.1, and when an assert unexpectedly fails I'd like the framework to output a message that is recognizable by the IDE as an error. What I'm seeing right now is: ------ Build started: Project: CBdbRangeSummary_test, Configuration: Debug Win32 ------ Run unit tests Assertion failed: 0, file .\CBdbRangeSummary.cpp, line 33 Running 3 test cases... Exception in "single_rnode_test": This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Build Time 0:00 CBdbRangeSummary_test - 0 error(s), 0 warning(s) ---------------------- Done ---------------------- Build: 1 succeeded, 0 failed, 0 skipped Thanks, Glen Knowles Centor Software Corporation

1 0

Re: [ublas-dev] Re: Boost Mathematicians
by Jeremy Graham Siek 06 Jul '04

06 Jul '04

Hi Paul, I agree with you. The use of operator* does not imply commutativity. Cheers, Jeremy On Jul 5, 2004, at 6:04 PM, Paul C. Leopardi wrote: > Hi all, > Reply to a sub-issue below. > Best regards > > On Tuesday 06 July 2004 02:58, Peter Schmitteckert wrote: > > This imples, that the elements of a matrix need not be commutative, > > having again consequences for general routines using operator*(), > > since this oftemn implies the commutativity of elements. > > Can anyone explain to me why operator* implies the commutativity of > elements? > The GluCat library ( http://glucat.sf.net ) uses operator* and its > elements > do not necessarily commute under multiplication. > > How would you use expression templates to implement a non-commutative > group > concept, or more to the point, a ring or an algebra? My first thought > for > this was to use operator* as it seems most natural, and in the case of > Clifford algebras, gives subalgebras isomorphic to the quaternions, > complex > numbers and real numbers. > > Of course, this discussion comes from a mathematical viewpoint rather > than a > computer science viewpoint, but I don't see why these viewpoints need > be > incompatible. > > > > Yahoo! Groups Sponsor > > ADVERTISEMENT > <lrec_companion_043004.gif> > <l.gif> > > Yahoo! Groups Links > > • To visit your group on the web, go to: > http://groups.yahoo.com/group/ublas-dev/ > > • To unsubscribe from this group, send an email to: > ublas-dev-unsubscribe(a)yahoogroups.com > > • Your use of Yahoo! Groups is subject to the Yahoo! Terms of > Service. > > _______________________________________________ Jeremy Siek <jsiek(a)osl.iu.edu> http://www.osl.iu.edu/~jsiek Ph.D. Candidate, Indiana University Bloomington C++ Booster (http://www.boost.org) _______________________________________________

1 0