September 2005 - Boost - lists.boost.org

[thread] condition suffering from lost wakup bug?
by Roland Schwarz 17 Sep '05

17 Sep '05

While reviewing the implementation of the condition variable implementation I came across a case where a "lost wakup" seems to take place. The example is admittedly artificial, but I think still correct code. (I hope someone can proof me wrong.) Could this be an indication that the current implementation is not using Alexander Terekhovs algorithm? If this really is the case we should definitely change our code. On the other side, I constructed the test case, by carefully studying Alexanders algorithm, in order to better understand the design. I did the tests on W2K with Vc7.1. My qeustions: 1) Is this corect code with respect to condition variable semantics (posix thread semantics?) 2) If 1) appplies: Can someone reproduce this on another platform too? Thank you, Roland #include <iostream> #include <boost/thread.hpp> using namespace boost; mutex guard; typedef mutex::scoped_lock lock_type; condition cond; long global_count = 0; long count_for_test = 10000; long global_number_of_threads = 0; long number_of_threads_for_test = 1000; bool global_flag = true; void do_work() { lock_type lock(guard); ++global_number_of_threads; cond.notify_one(); while (global_count < count_for_test) cond.wait(lock); } void do_flag() { lock_type lock(guard); ++global_number_of_threads; cond.notify_one(); while (global_count < count_for_test) { cond.wait(lock); global_flag = false; // Step 3: The following signal occasionally // is beeing lost. See below. cond.notify_one(); } } int main() { thread_group pool; for (long i=0; i < number_of_threads_for_test; ++i) { pool.create_thread( do_work ); } pool.create_thread( do_flag ); { // we wait until all threads are up lock_type lock(guard); while (global_number_of_threads < number_of_threads_for_test+1) cond.wait(lock); } // the loop will run for some time and // then suddenly deadlock for (long j=0; j<count_for_test; ++j) { lock_type lock(guard); ++global_count; // Step 1: We do a heavy notification cond.notify_all(); // Step 2: Then we wait on the same condition. // Since we hold the lock we can be sure // all threads are waiting at this point. // Entering the below wait should // atomically wait and release the lock. // In turn I expect all threads being woken up, // except the main thread since the wait // occures after the notify_all(). // The do_flag thread will signal after // we have entered the below wait. // However the signal occasionally // is beeing lost. Is this kind of a // "lost wakup"? while(global_flag) cond.wait(lock); // deadlocks // When you break in with the debugger // as the deadlock occurs, you can see // that the flag indeed is false, which is a // proof that the signal has been sent. global_flag = true; } pool.join_all(); //result check std::cout << "We should get here without a deadlock\n"; return 0; }

5 21

Re: [boost] Checked Integral Class
by Matt Doyle 17 Sep '05

17 Sep '05

> matt, i don't think your code example disambiguates what rob > and i are > disagreeing on > when you say: > > MyCv c = a + b; // Should fail > > you don't say why you think it should fail. there are (at least) 3 > possibilities: > a) at compile time (because it is an error to try to assign a > 0-20 number to > a 0-10 number) > b) at runtime, during the assignment (because it is an error > to assign a > 0-20 number to a 0-10 number if it is outside the 0-10 range) > c) at runtime, during the addition (because it is an error to > add two 0-10 > numbers if they add up to more than 10) > > i think a) and b) are both useful, and i think rob is advocating c) Your correct, I had thought I understood what Rob is talking about. I think what's causing confusion is that there are really two issues - compile time behavior and runtime behavior. I'm getting the two conditions mixed together because I need both. I need to defend against all three possibilities, I need to catch the programmers mistakes at compile time but I also need to catch the application errors at run time. Scanned by Fortigate {X3BTB534}

1 0

Re: [boost] [filesystem] revised function to determineavailablefile system space
by Greer, Joe 17 Sep '05

17 Sep '05

> In looking at this a bit further, both POSIX and windows distinguish > between > total free space and free space available "to nonprivileged process" > (POSIX) > or "to caller" (Windows). > > To accommodate this, we might have: > > boost::uintmax_t capacity(path const &); > boost::uintmax_t total_free_space(path const &); > boost::uintmax_t available_free_space(path const &); > IMO, total_free_space() and available_free_space() should be tied together so that you can make some relationship between them. If they are implemented as separate calls, then you don't really know what disk activity went on between the first and second calls. I can see a case where the total_free_space might be < than the available_free_space if you called the functions in the wrong order and there was disk activity going on. joe

2 1

Re: [boost] Checked Integral Class
by Matt Doyle 17 Sep '05

17 Sep '05

> From: "michael toksvig" <michaeltoksvig(a)yahoo.com> > > > "Rob Stewart" <stewart(a)sig.com> wrote in message > > > > news:200509161700.j8GH0nHo017101@shannonhoon.balstatdev.susq.com... > > > It's surprising for the result type to have a less restrictive > > > range than the inputs. > > > > add two numbers in the 1-10 range, and you invariably end > up with a number > > in the 2-20 range > > Yep. However, when considering constrained ranges, I find it > surprising that the result would be *permitted* to exceed the > constraints of the inputs. > > IOW, I'd have expect the result to be constrained to be 2-10. > Yes, that means that combinations exist that violate that > constraint, but at least it wouldn't surprise me. > <snip> YES, that's exactly the point I was trying to make earlier - you just did a much better job of explaining it :) IMO, the constraints and/or policies set forth when the type was defined must apply for the lifetime of the type. Matt Scanned by Fortigate {X3BTB534}

2 1

Re: [boost] Checked Integral Class
by Matt Doyle 17 Sep '05

17 Sep '05

> > Maciej Sobczak wrote: > > > > In my opinion both approaches have their uses, just like > std::vector and > > boost::array. > > > > Right. We could support both ways by making the type of range > the value > is checked against configurable. I think of a static_range<> for > compile-time checked values and dynamic_ranges to be setup at runtime. Question though. Which is going to be more useable; having separate methods for static and runtime, or having one that checks the range at compile time and then continues to maintain that original policy for the lifetime of the type? Actually, that might be something that be selectable in the policy class, if it's possible, something like apply_contraints_at [COMPILE_TIME, RUN_TIME, BOTH] Any thoughts? Matt Scanned by Fortigate {X3BTB534}

1 0

Vault: Missing Content? Search?
by Caleb Epstein 16 Sep '05

16 Sep '05

I know content disappaeared from the "Vault" at http://boost-consulting.com/vault/ not long ago, but I thought it had been restored. I am looking for the "factory3.zip "file that used to be there, but I'm unable to find it. In fact most of the directories are currently empty. Also, is there any way to make this interface searchable? While the current neat directory structure is nice, it sure makes it difficult to find an arbitrary file that might be there (e.g. does factory belong in "Containers", "Generic Programming", "Miscellaneous" or someplace else?). A search box would help a lot as the content is expanded over time. -- Caleb Epstein caleb dot epstein at gmail dot com

3 2

Boost regression notification (2005-09-16 [HEAD])
by Douglas Gregor 16 Sep '05

16 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-16T05:00:20Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. typeof Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 259 failures in 17 libraries: algorithm/string (1) concept_check (14) date_time (5) filesystem (8) foreach (7) graph (4) iostreams (1) math (6) mpl (2) parameter (17) python (1) regex (36) serialization (40) spirit (2) thread (24) typeof (87) wave (4) |algorithm/string| regex: gcc-3_3-darwin |concept_check| stl_concept_covering: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 msvc vc-7_1 vc-7_1 |date_time| testlocal_time_iterator: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc testlocal_time_period: gcc-2.95.3-linux msvc |filesystem| convenience_test: msvc default_name_check_test: msvc fstream_test: msvc large_file_support_test: msvc operations_test: msvc operations_test_dll: msvc path_test: msvc path_test_dll: msvc |foreach| user_defined: cw-8_3 cw-9_4 cw-9_5-darwin msvc vc-6_5 vc-6_5-stlport vc-7_0 |graph| graphviz_test: vc-7_1 vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |iostreams| regex_filter_test: gcc-3_3-darwin |math| octonion_test: gcc-4_0-darwin gcc-4_0-darwin quaternion_test: gcc-4_0-darwin gcc-4_0-darwin special_functions_test: gcc-4_0-darwin gcc-4_0-darwin |mpl| size_t: gcc-4_0-darwin gcc-4_0-darwin |parameter| basics: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux efficiency: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc macros: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux sfinae: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc unnamed: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux vc-7_1 |python| data_members: msvc |regex| bad_expression_test: gcc-3_3-darwin captures_example: gcc-3_3-darwin captures_test: gcc-3_3-darwin collate_info: gcc-3_3-darwin concept_check: gcc-3_3-darwin credit_card_example: gcc-3_3-darwin grep: gcc-3_3-darwin icu_example: gcc-3_3-darwin mfc_example: gcc-3_3-darwin object_cache_test: gcc-3_3-darwin partial_regex_grep: gcc-3_3-darwin partial_regex_match: gcc-3_3-darwin posix_api_check: gcc-3_3-darwin posix_api_check_cpp: gcc-3_3-darwin recursion_test: gcc-3_3-darwin regex_config_info: gcc-3_3-darwin regex_dll_config_info: gcc-3_3-darwin regex_grep_example_1: gcc-3_3-darwin regex_grep_example_2: gcc-3_3-darwin regex_grep_example_3: gcc-3_3-darwin regex_grep_example_4: gcc-3_3-darwin regex_iterator_example: gcc-3_3-darwin regex_match_example: gcc-3_3-darwin regex_merge_example: gcc-3_3-darwin regex_regress: gcc-3_3-darwin regex_regress_dll: gcc-3_3-darwin regex_replace_example: gcc-3_3-darwin regex_search_example: gcc-3_3-darwin regex_split_example_1: gcc-3_3-darwin regex_split_example_2: gcc-3_3-darwin regex_timer: gcc-3_3-darwin regex_token_iterator_eg_1: gcc-3_3-darwin regex_token_iterator_eg_2: gcc-3_3-darwin static_mutex_test: gcc-3_3-darwin msvc wide_posix_api_check_cpp: gcc-3_3-darwin |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |spirit| traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |thread| test_barrier: msvc test_barrier_lib: intel-9.0-linux msvc test_condition: msvc test_condition_lib: intel-9.0-linux msvc test_mutex: msvc test_mutex_lib: intel-9.0-linux msvc test_once: msvc test_once_lib: intel-9.0-linux msvc test_read_write_mutex: msvc test_read_write_mutex_lib: intel-9.0-linux msvc test_thread: msvc test_thread_lib: intel-9.0-linux msvc test_tss: msvc test_tss_lib: intel-9.0-linux msvc test_xtime: msvc test_xtime_lib: intel-9.0-linux msvc |typeof| data_member_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux data_member_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 function_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux function_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 msvc function_ptr_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux function_ptr_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 function_ref_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux function_ref_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 lvalue_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux lvalue_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 msvc member_function_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux member_function_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 modifiers_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux modifiers_native: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 template_int_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux template_int_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 template_tpl_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux template_tpl_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 msvc template_type_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux template_type_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 type_emulation: borland-5_6_4 cw-8_3 cw-9_4 cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux type_native: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-8_1 intel-win32-9_0 intel-win32-9_0 intel-win32-9_0 |wave| test_re2c_lexer: intel-9.0-linux test_slex_lexer: intel-9.0-linux testwave: gcc-3.3.6-linux intel-9.0-linux

1 0

stl_concept_covering.cpp terminally broken in 1.33.x ?
by John Maddock 16 Sep '05

16 Sep '05

Looking at the regressions for 1.33.1 stl_concept_covering.cpp seems not to compile with any compiler at present. Looking at the source there is one obvious error: out = std::fill_n(out, n, value); But fill_n returns void ! Then there are lots of preprocessor sections along the lines of: #if defined(__GNUC__) typedef less_than_op_first_archetype<> FT; typedef less_than_op_second_archetype<> T; #elif defined(__KCC) // The KAI version of this uses a one-argument less-than function // object. typedef less_than_comparable_archetype<> T; typedef convertible_to_archetype<T> FT; #endif forward_iterator_archetype<FT> fi; T value(dummy_cons); fi = std::lower_bound(fi, fi, value); Which can clearly never compiler on any compiler other than GCC or KCC. However, fixing these issues still doesn't get the code compiling on any platform I have access to. Some of these will be std lib conceptual errors, but *something* should compile this source, otherwise what's the point? Regards, John.

1 0

Fwd: Boost thread library bugs
by Sean Parent 16 Sep '05

16 Sep '05

Begin forwarded message: > From: "Mike Schuster" <schuster(a)adobe.com> > Date: September 15, 2005 6:11:03 PM PDT > To: "Sean Parent" <sparent(a)adobe.com> > Subject: RE: Boost thread library bugs > > > I just downloaded it and took a look. > > Bugs 1) and 2) still exist. > > Bug 3): read_write_mutex had a major rewrite, and looking at the new > code, bug 3) appears to have been discovered and addressed. > However, the > code is quite a bit more complicated (1700 lines versus 1100 lines). I > will do some testing and more investigation in the next few days. > > (By the way, my implementation of a "most useful subset" (in my > opinion) > of read_write_mutex is 100 lines. Boost may have gone overboard > here at > the price of performance.) > > -Mike > > -----Original Message----- > From: Sean Parent [mailto:sparent@adobe.com] > Sent: Thursday, September 15, 2005 3:46 PM > To: Mike Schuster > Subject: Re: Boost thread library bugs > > Have you looked at 1.33.0 yet to see if any of these are fixed? > Sean >

3 2

[regex][1.33.1] Build with MinGW+STLport-5 fails.
by Rene Rivera 16 Sep '05

16 Sep '05

Ran into a problem while verifying building. With the combination of MinGW 3.4.2 - Runtime 3.8 - STLport-5 the *release* variant of Boost.Regex fails to build with this error: In file included from C:/DevRoots/Boost/boost_1_33/boost/regex/v4/regex.hpp:97, from C:/DevRoots/Boost/boost_1_33/boost/regex.hpp:31, from C:\DevRoots\Boost\boost_1_33\libs\regex\build\../src/instances.cpp:30: C:/DevRoots/Boost/boost_1_33/boost/regex/v4/instances.hpp:188: error: duplicate explicit instantiation of `void boost::match_results<BidiIterator, Allocator>::maybe_assign(const boost::match_results<BidiIterator, Allocator>&) [with BidiIterator = const char*, Allocator = stlp_std::allocator<boost::sub_match<const char*> >]' C:/DevRoots/Boost/boost_1_33/boost/regex/v4/instances.hpp:195: error: duplicate explicit instantiation of `void boost::re_detail::perl_matcher<BidiIterator, Allocator, traits>::construct_init(BidiIterator, BidiIterator, boost::match_results<BidiIterator, Allocator>&, const boost::basic_regex<typename traits::char_type, traits>&, boost::regex_constants::match_flag_type) [with BidiIterator = const char*, Allocator = stlp_std::allocator<boost::sub_match<const char*> >, traits = boost::regex_traits<char, boost::cpp_regex_traits<char> >]' C:/DevRoots/Boost/boost_1_33/boost/regex/v4/instances.hpp:196: error: duplicate explicit instantiation of `bool boost::re_detail::perl_matcher<BidiIterator, Allocator, traits>::match() [with BidiIterator = const char*, Allocator = stlp_std::allocator<boost::sub_match<const char*> >, traits = boost::regex_traits<char, boost::cpp_regex_traits<char> >]' C:/DevRoots/Boost/boost_1_33/boost/regex/v4/instances.hpp:197: error: duplicate explicit instantiation of `bool boost::re_detail::perl_matcher<BidiIterator, Allocator, traits>::find() [with BidiIterator = const char*, Allocator = stlp_std::allocator<boost::sub_match<const char*> >, traits = boost::regex_traits<char, boost::cpp_regex_traits<char> >]' It looks like the code is supposed to be guarded for GCC but it might be conflicting since it's STLport also. Any ideas? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

2 2