- Boost - lists.boost.org

static_assert, documentation nit
by Glen Knowles 10 Jul '04

10 Jul '04

Near the beginning of the documentation on the website the example: Illegal use of COMPILE_TIME_ASSERTION_FAILURE<false> Should, I believe, read: Illegal use of STATIC_ASSERTION_FAILURE<false> Glen Knowles Centor Software Corporation

3 2

Problem with Linux test reports
by Joaquín Mª López Muñoz 10 Jul '04

10 Jul '04

Regression tests for Linux are updating OK every day, but the advanced developer and user reports seem to be stuck at Jul 5th. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 5

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 09 Jul '04

09 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