- 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] > On Jul 9, 2004, at 7:10 PM, Glen Knowles wrote: > >> 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. :) > > Well actually keep try-locking both ways is what I've been > doing. I'd agree with you that in a heavily contested > context, performance could theoretically suffer arbitrarily badly. > > > One solution to this problem would be mutex::operator< > > <nod> I just implemented lock_both::lock two ways: Once > just keep try-locking both ways, and once locking in the > order of the addresses of the locks (with only two locks in > the test, this was a safe operator<). My test looks like: The problem case for spinning is when one thread gets the locks and the holds them for a non-trivial length of time. During that time the other, spinning thread, just wastes cpu as fast as it can. This just gets magnified as more threads are involved. Glen

2 1

Boost sandbox
by Edward Diener 10 Jul '04

10 Jul '04

How does one access files in the Boost sandbox ? I am particular interested in libraries that have been reviewed and approved after the 1.31 release. When I get the latest Boost from CVS I do not see those libraries there. I am assuming they are somewhere, perjaps in the sandbox. How can I get them to try them out before the next release of Boost ?

2 3

Latest CVS doc links broken
by Edward Diener 10 Jul '04

10 Jul '04

The documentation links for lambda and thread in the latest Boost CVS do not go to a valid page.

1 0

[regression] Link failures for intel-win32-7.1-vc6-stlport-4.5.3
by Rene Rivera 10 Jul '04

10 Jul '04

Before John Maddock left on vacation, lucky him, he asked me to look into how to fix the problems with linking failing under some circumstances for this toolset in the regression tests. His supposition was that the auto-linking was not generating the correct name for linking, and that we needed to fix either the auto-linking or the build to be consistent about the naming. In looking at what is failing, as compared to what is not failing, my conclusion differs. The problem is that the failing tests are using auto-linking at all. As according to John himself one should not use it in the regression tests: "Please note however that this Jamfile will only build with compilers that do actually support auto-linking, so it should not be added to the regular regression tests." (http://boost.org/more/separate_compilation.html#testing) -- And the tests in question, signals, accidentally use both auto-linking and direct linking. There are two ways of fixing this problem: a) I automatically and globally <define>BOOST_ALL_NO_LIB=1 for all targets within Boost, or, b) We change individually each test that uses an auto-link enabled library to <define>BOOST_ALL_NO_LIB=1 I'm currently leaning towards (b), even if it is more work, as it has less chances of breaking other tests and/or the regular builds of examples and the libraries themselves. Comments? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

2 4

Proposed patch to config/compiler/visualc.hpp
by Michael Glassford 10 Jul '04

10 Jul '04

Two minor changes for WinCE compatibility, to be used by Boost.Threads. I can commit the changes myself, but didn't want to mess with the config files without bringing it up here first. Mike Index: boost/config/compiler/visualc.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/config/compiler/visualc.hpp,v retrieving revision 1.37 diff -u -r1.37 visualc.hpp --- boost/config/compiler/visualc.hpp 22 Jun 2004 12:33:06 -0000 1.37 +++ boost/config/compiler/visualc.hpp 6 Jul 2004 17:44:02 -0000 @@ -17,7 +17,7 @@ // turn off the warnings before we #include anything #pragma warning( disable : 4503 ) // warning: decorated name length exceeded -#if _MSC_VER <= 1200 // 1200 == VC++ 6.0 +#if _MSC_VER <= 1201 // 1200 == VC++ 6.0, 1201 == EVC4.2 #pragma warning( disable : 4786 ) // ident trunc to '255' chars in debug info # define BOOST_NO_DEPENDENT_TYPES_IN_TEMPLATE_VALUE_PARAMETERS # define BOOST_NO_VOID_RETURNS @@ -73,6 +73,11 @@ # define BOOST_NO_INTRINSIC_WCHAR_T #endif +#ifdef _WIN32_WCE +# define BOOST_NO_THREADEX +# define BOOST_NO_GETSYSTEMTIMEASFILETIME +#endif + // // check for exception handling support: #ifndef _CPPUNWIND

2 2

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