July 2004 - Boost - lists.boost.org

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

10 Jul '04

> From: Howard Hinnant [mailto:hinnant@twcny.rr.com] > >>>> rw_mutex m; > >>>> > >>>> void invitation_for_deadlock() > >>>> { > >>>> read_lock r(m); > >>>> // ok to read > >>>> upgradable_read_lock ur(m); > >>>> r.unlock(); > >>>> write_lock w(ur); > >>>> // ok to write > >>>> } > >>>> > > > > It only deadlocks under a race, but I'm not sure it's scary. It's > > something I'm use to seeing in the presents of r/w locks. > > If r/w locks regularly encourage deadlocks, I am not anxious > to further pursue them. I'm not convinced of that however > (and hope I won't be). > I'm seeking a system which makes it easy to avoid deadlocks, > race conditions, and leaked locks. Admittedly any system can > be abused. > But a good system will naturally reduce accidental abuse, > while not necessarily preventing intentional abuse. Holding multiple locks regularly encourages deadlocks, if you don't do that you'll be okay. ;) Anything else I think you have to be careful. That's a big part of why I'm not so worried, I think the vast majority of cases only require one lock at a time, beyond that you're probably trying to do something complex. > There's not overhead in the lock, but in the rw_mutex to > support both read/write and upgradable_read. But hanging a > try_promote on multiple upgradable read locks really makes me > nervous. Doing so (imho) makes deadlock significantly more > likely (see my post with lock_both/transfer_lock example). > > Fwiw, here's what I'm seeing that is scaring me: > > A holds ur. > B holds r. > A waits for B to unlock r so it can unlock ur and lock w. > B waits for A to unlock ur so it can lock ur. Yes, multiple readers all trying to upgrade. What made it interesting to me is that its one of the few cases where a deadlock detector gets to kill multiple waiters. AFAIK r/w locks only makes sense if you're going to hold read locks for a period of time, otherwise you're better off just using a regular mutex. Glen

2 1

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

10 Jul '04

> From: Howard Hinnant [mailto:hinnant@twcny.rr.com] > My intention with the read/write lock stuff was simply that > these guys needed to at least support try locks. That is > needed so that you can do assign-like locking between two objects: > > { > lock_both<write_lock, read_lock> l(a.mut(), b.mut()); > a = b; > } > > Without try locks, lock_both can't be made to work without risking > deadlock. Lock_both can be made to work with try locks? Either you have a way to deterministicly set the order you lock the mutexes or you have problems. You can avoid deadlocking with try lock, but you will fail to get the pair of locks in cases were you would have gotten it by waiting. I suppose you could just keep try-locking both ways until you get it, but that's not good for performance. :) One solution to this problem would be mutex::operator< Glen

2 1

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

10 Jul '04

From: Howard Hinnant [mailto:hinnant@twcny.rr.com] >On Jul 9, 2004, at 4:11 PM, Peter Dimov wrote: >>> rw_mutex m; >>> >>> void invitation_for_deadlock() >>> { >>> read_lock r(m); >>> // ok to read >>> upgradable_read_lock ur(m); >>> r.unlock(); >>> write_lock w(ur); >>> // ok to write >>> } >>> >>> It took me awhile to spot the deadlock in the above code. Does >>> anyone else see the above code as scary? (scary as in looks ok but isn't). >>> Or is the deadlock obvious to everyone else (and thus not scary)? >> >> Not scary, IMO, even if not obvious, because it always deadlocks, as >> soon as you attempt the "idiom". You can't miss it. > > I'm not following "always deadlocks". If only one thread enters, at > what point does it deadlock (assuming no other thread playing with m)? > Experimentally running through this on my prototype implementation > with a single thread isn't deadlocking. But perhaps my prototype is buggy? It only deadlocks under a race, but I'm not sure it's scary. It's something I'm use to seeing in the presents of r/w locks. I don't know where you left off, are you implementing single upgradeable or multiple upgradeables? If only one upgradeable can exist in the system at a time then, what would deadlock, will result in a failure to create a second upgradable lock, IIUC. You can always manufacture ways to deadlock, I'd still vote for just hanging a try/timed_promote() on all read locks. Unless perhaps there's overhead in upgradable_read_lock that isn't required in read_lock? Glen

2 1

Re: [boost] Re: Pretty Good Initialization Library
by brangdon＠cix.compulink.co.uk 10 Jul '04

10 Jul '04

In-Reply-To: <200407081913.i68JD5d00852(a)tesh.systems.susq.com> stewart(a)sig.com (Rob Stewart) wrote (abridged): > I overstated the case. How many types will one have to overload > operator<< (and operator>>) for? The combinatorial explosion > (containers X types to use with the initialization library X 2) > will be overwhelming. You've lost me. Why does the choice of operator<<() instead of operator,() produce a combinatorial explosion of overloads? It's mostly just a change of name. > I still think of operator<< and operator>> as doing formatted I/O. Well, at one time we all thought it did bitwise shifts. -- Dave Harris, Nottingham, UK

2 1

CVS Commit issue
by Robert Ramey 09 Jul '04

09 Jul '04

I've got my issues re cygwin path for ssh access squared away. Now I want to check in some files. I'm using the book "Open Source Development with CVS" as a guide. I get to the point of commit and I get. Stuck again. It seems to me that this is something out of my control - or is it? Here is my screen dialog $ cvs -d:ext:ramey@cvs.sourceforge.net:/cvsroot/boost commit -m "initial check ramey(a)cvs.sourceforge.net's password:<password entered here> cvs commit: failed to create lock directory for `/cvsroot/boost/boost/boost/archive' (/cvsroot/boost/boost/boost/archive/#cvs.lock): No such file or directory cvs commit: lock failed - giving up cvs [commit aborted]: lock failed - giving up I would appreciate any help anyone has to offer. Robert Ramey

2 1

cvs access problems
by Robert Ramey 09 Jul '04

09 Jul '04

I'm trying to check in the serialization system and am having some problems. According to the sourceforge.net docs I need to "register" my host with my local ssh by logging in in the following manner. $ ssh -l ramey cvs.sourceforge.net Could not create directory '/home/Robert Ramey/.ssh'. The authenticity of host 'cvs.sourceforge.net (66.35.250.207)' can't be established. DSA key fingerprint is 02:ab:7c:aa:49:ed:0b:a8:50:13:10:c2:3e:92:0f:42. Are you sure you want to continue connecting (yes/no)? yes Failed to add the host to the list of known hosts (/home/Robert Ramey/.ssh/known_hosts). ramey(a)cvs.sourceforge.net's password: Last login: Thu Jul 8 22:22:39 2004 from 226-146.adsl2.netlojix.net Welcome to cvs1.sourceforge.net This is a restricted Shell Account You cannot execute anything here. Connection to cvs.sourceforge.net closed. $ Ssh seems to have difficulty creating/updated a file of known_hosts in my home directory. I'm using windows XP with cygwin shell. I've tried changing environmental variables $HOME, and others but nothing seems to make a difference. Does anyone have any suggestion. I realize that this isn't the best place to post this but I'm kind if desperate. Thank you for your patience. Robert Ramey

4 6

Re: lightweight mutex
by Dan 09 Jul '04

09 Jul '04

Just a note on the lightweight mutex for windows OS using Interlocked operations: I had one like this before (came with doug lee's allocator) and I ran some benchmarks and saw a ~10% improvement in performance in a non-contention situation. Now that benchmark may or may not have been valid, it's too long ago for me to say with certainty, but it raises the question, what are the numbers here? Also one does not need to use a spin lock on a ref counted implementation. A much faster (and safer) way to do that is just using InterlockedIncrement and InterlockedDecrement when changing the ref count. I beleive this is what most popular ref counting implementations use.

3 2

[Boost-bugs] [ boost-Bugs-988124 ] Borland compiler error with Pool, boost::pool_allocator
by SourceForge.net 09 Jul '04

09 Jul '04

Bugs item #988124, was opened at 2004-07-09 10:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=988124&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David W. Thomas (davidwt) Assigned to: Nobody/Anonymous (nobody) Summary: Borland compiler error with Pool, boost::pool_allocator Initial Comment: This Borland compiler error occurs with boost release versions 1.30.2 and 1.31.0. It also occurs with the latest CVS checkout as of July 9, 2004. I've tried this on two Win2000 computers with totally different hardware (Intel, AMD). Borland compilers from Borland Builder5 and from Borland BuilderX both generate an internal compiler error with a typedef of pool_allocator<int>. The source code file t.cpp contains: #include <boost/pool/pool.hpp> typedef boost::pool_allocator<int> node_alloc; Here is a copy of the DOS window for the two compiles: D:\>c:\borland\CBUILDER5\BIN\bcc32 - I\src.misc\boost;c:\borland\CBUILDER5\include t.cpp Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland t.cpp: Fatal F1004 t.cpp 2: Internal compiler error at 0x46f530 with base 0x400000 Fatal F1004 t.cpp 2: Internal compiler error D:\>c:\borland\CBUILDERX\BIN\bcc32 - I\src.misc\boost;c:\borland\CBUILDERX\include t.cpp Borland C++ 5.6.4 for Win32 Copyright (c) 1993, 2002 Borland t.cpp: Fatal F1004 t.cpp 2: Internal compiler error at 0x4394f6 with base 0x400000 Fatal F1004 t.cpp 2: Internal compiler error ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=988124&group_i… ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

RE: [boost] Question about Boost.Random
by Kris Thielemans 09 Jul '04

09 Jul '04

Hi Anders you probably should read my email on this of a few days ago. The simple answer is to use typedef boost::variate_generator<engine_t&, distribution_t> rng_t; (i.e. with ref) It all makes sense, it's just hard to get from the doc in my opinion. Kris > // The following program illustrates a problem in Boost.Random. > > // Is this the desired behavior? > > // If so, what is the reason for this? > > // I use Boost version 1.31 and GCC version 3.3.3 on Suse 9.1 > > #include <vector> > #include <algorithm> > #include <boost/random.hpp> > > // Definition of the random number generator > typedef boost::mt19937 engine_t; > typedef boost::uniform_int<int> distribution_t; > typedef boost::variate_generator<engine_t, distribution_t> rng_t; > > int main() > { > const unsigned int N = 13, A = 0, B = 1000; > std::vector<int> run1(N), run2(N), run3(N); > > // Generate some random integers > { > engine_t engine; > distribution_t distribution(A,B); > rng_t rng(engine, distribution); > std::generate(run1.begin(), run1.end(), rng); > } > > // Verify that I get the same sequence if I start again > { > engine_t engine; > distribution_t distribution(A,B); > rng_t rng(engine, distribution); > std::generate(run2.begin(), run2.end(), rng); > } > > // It appears that the generator restarts for each generate, since > // the generate algorithm creates a copy of the functor so that > // its state is lost > { > engine_t engine; > distribution_t distribution(A,B); > rng_t rng(engine, distribution); > std::generate(run3.begin(), run3.begin()+N/2, rng); > std::generate(run3.begin()+N/2, run3.end(), rng); > } > > // For me it would seem more natural if the engine class would be a > // singleton, so that there can be only one object of any particular > // random generator engine type. > > // Our purpose for using random numbers is to simulate physical processes. > // I can't think of a case when there would be a need for several random > // engines, even if there can of course be many different random > // distributions in an application. > > // Having the same random number sequence in different parts of a > simulation > // can probably create very strange behaviour, since the numbers from the > // different engines of the same type will be perfectly correlated. > > // Perhaps other applications have use of several random engines? > > for(unsigned i=0; i<N; ++i) { > if(i==N/2) > std::cout<<"Halfway there!"<<std::endl; > std::cout > <<run1[i] > <<" == "<<run2[i] > <<" == "<<run3[i] > <<std::endl; > } > > return 0; > } > > // Anders Edin > // Sidec Technologies AB > >

1 0

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

09 Jul '04

Hi Paul, Yes, you've got the idea. The following document shows one such attempt to construct a system of traits for algebraic concepts: http://www.cs.rpi.edu/~schupp/entries/SOFTWARE/simpl/doc/AlgCpp.pdf also, more information is available starting at: http://www.cs.rpi.edu/~schupp/entries/SOFTWARE/simpl/ Cheers, Jeremy On Jul 7, 2004, at 7:32 PM, Paul C. Leopardi wrote: > Jeremy, Dave, > I think I get it. See below. > Best regards > On Thursday 08 July 2004 02:25, David Abrahams wrote: > > Jeremy Graham Siek <jsiek(a)osl.iu.edu> writes: > > > group_traits<T>::is_commutative > > is_commutative_group<T>::type > > is_commutative_group<T>::type::value > > OK, for a type where you have one operation (a group). > For a two operation type, I suppose you would then want > > is_ring<T>::type > is_ring<T>::type::value > > is_commutative_ring<T>::type > is_commutative_ring<T>::type::value > > Along these lines, you could build a header file called > arithmetic_traits.hpp > or something similar. The object of this file would be to describe > some of > the semantics of operator+, operator* and possibly other operators > when used > with various types. Eg. you could have say > > is_algebra< framed_multi<T,L,H>, T>::type > is_algebra< framed_multi<T,L,H>, T>::scalar_type > > This header would also be used to define the zero element of addition > and the > identity element of multiplication, if it exists. > > Once this header is established, you could build template libraries > which > perform arithmetic according to the axioms embodied in the traits. > Such a > library would not eg. assume that multiplication is commutative, it > would > check this at compile time. > > Note that there would also need to be a distinction between > approximate and > exact arithmetic. This especially affects associativity, where eg. > addition > of real numbers behaves differently from addition of floating point > numbers > due to loss of precision. eg. > http://h18009.www1.hp.com/fortran/docs/vf-html/pg/pg1round.htm > http://www.ibiblio.org/pub/languages/fortran/ch4-6.html > > > > > 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