- Boost - lists.preview.boost.org

RE: [boost] Re: Lock unification [was: Boost.Threads: Do we need all those mutexes?]
by Batov, Vladimir 15 Jul '04

15 Jul '04

> Christopher Currie wrote: > > I can infer that the apparent justification for unification would be to > > allow a single lock to be used in different ways, but I have a hard time > > imagining a use case where this would be as clear and as error-resistant > > as separate scopes with separate locks. If anyone has one, or any other > > rationale, please respond. > > The main motivation behind the idea of unifying the lock types (and > mutex types) is simplification of concepts, I believe. > > Mike [Batov, Vladimir] I would not call it 'simplification' as it can send a wrong message but rather 'streamlining'. It's because conceptually (and in implementation) try_lock = timed_lock(time=0) scoped_lock = timed_lock(time=infinite) Although I have to agree that from user perspective those locks are distinct and it makes sense to me to provide thin timed_lock, try_lock, blocking_lock interfaces for the majority of mainstream uses.

1 0

RE: [boost] Re: Lock unification
by Batov, Vladimir 15 Jul '04

15 Jul '04

I like the suggestion of constructing an appropriate lock via the appropriate constructor rather than a function (after all, that's what constructors are for :-) ). Although I'd probably try being more explicit typedef scoped_lock Lock; Lock l(m); // block Lock l(m, Lock::try); // try Lock l(m, Lock::time(33)); // timed Lock l(m, Lock::deferred); // deferred BTW, I love 'deferred'. IMHO it is very good and descriptive name for a parameter. Much better than we had before (was it block/non-block?). > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of David Abrahams > Sent: Friday, 16 July 2004 7:24 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: Lock unification > > "Eric Niebler" <eric(a)boost-consulting.com> writes: > > > David Abrahams wrote: > >> "Eric Niebler" <eric(a)boost-consulting.com> writes: > >> > >>>I continue to believe that a better interface for a unified lock > >>>involves descriptively named helper functions: > >>> > >>>scoped_lock l1( m ); // lock unconditionally > >>>scoped_lock l1 = defer_lock( m ); // don't lock > >>>scoped_lock l2 = try_lock( m ); // try lock > >>>scoped_lock l3 = timed_lock( m, t ); // timed lock > >>> > >>> It's just as clear as you could hope for, > >> I'm not convinced it is. It potentially puts information about the > >> kind of locking being done very far from the actual call that does > >> locking. > > > > > > True, but the other design under consideration doesn't help with > > that. It requires two-step construction for some constructs which > > could result in code like: > > > > scoped_lock l( m, false ); > > maybe_takes_the_lock_i_dont_know( l ); > > I don't know what you're referring to. I don't see any two-step > construction going on there. Links or examples, please? > > >>>and it's extensible. I feel that the single lock c'tor with a bool > >>>arg is less readable and rather inflexible. > >> Inflexible how? > >> > > > > User's can't add more constructors if they want a different locking > > strategy, but they can add as many helper function as they like. For > > instance, they could define a function that tried to take a timed_lock > > and logs failures. Or throws an exception. Or they could write a > > lock_if helper that takes a predicate. And they can do all that with > > simple one-step construction syntax. It's more concise and it permits > > the lock declaration to appear in the condition of if statements. > > Sorry, I missed the "single lock ctor" part. I think I agree with > you there. > > BTW, it just occurred to me that > > timed_lock(m, 0) > > could potentially generate different code from > > timed_lock(m, some_int) > > If we can detect literal zero... which I think is possible. > > What about: > > scoped_lock l(m); // block > scoped_lock l(m, 0); // try > scoped_lock l(m, 33); // timed > > scoped_lock l(m, deferred); // deferred > scoped_lock l(deferred(m)); // alternate > > ?? > > -- > Dave Abrahams > Boost Consulting > http://www.boost-consulting.com > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: Boost.Threads: Do we need all those mutexes?
by Iggy Veresov 15 Jul '04

15 Jul '04

While reading a discussion concerning different types of mutexes and guards in Boost, I thought it would be pertinent to highlight another possible approach to implement a multithreading library. In libMAGE (http://libmage.sourceforge.net/) we have a universal lock (unilock) abstraction, that provides a common way for construction of different lock managers (exclusive, read/write and even more complicated ones) with replaceable scheduling strategies. Furthermore, they can be easily adapted to mutex interface and used, for example, in methods of condition objects. /Igor Veresov

1 0

explicit-failures-markup.xml validating
by Bart Garst 15 Jul '04

15 Jul '04

I noticed a URL in boost/status/explicit-failures-markup.xml that can be used for validating. I made a couple changes to that file and ran it through the validator. My changes validate ok but there were other errors with the algorithm/string entries. Will these errors cause all entries in this file to not make it into the regression output? Thx, Bart

3 2

Re:Re: [boost] Re: Serialization Menu
by Robert Ramey 15 Jul '04

15 Jul '04

Mattias Flodin wrote: >> (ii) Requiring all documentation to support a no-script option. >In think (ii) is an absolute requirement. I find myself using >text-based browsers from time to time, especially when working across >an SSH connection, and I get quite annoyed by some documentation sites >that navigation exclusively though Javascript. I would hate for boost >to go the same way. >In addition to some text browsers not supporting Javascript at all, >the CERT has on numerous occasions advised that Javascript be disabled >in browsers such as IE for security reasons, and some companies make >that a policy decision. Actually I agree with this. I will change the serialization navigation pain so that it works on browsers that don't support scripting. This would leave the navigation pane but it would always be maximally expanded for browsers that don't support it. I think that would fulfill the requirement of making the documentation universally useable and still permit us to use the facility we like most of the time. A real problem with this collapsible tree navigation is that I generated it by hand. OK for a one time deal but not a great long term idea. As I understand it - the boost.book idea is the long term solution. I don't know if it now has the capability to generate such a navigation pane from the source documentation - but it should. Also if the formatting were all in the cascaded style sheet it would go a long way to avoiding disputes about things like aesthetics. It would be practical as well. For example one using a text based browser might use a different CSS. Feel free to take this with a grain of salt because I've barely looked at it. Robert Ramey

1 0

multi_array: a patch for SGI MIPSpro
by Synge Todo 15 Jul '04

15 Jul '04

Dear Boosters, About two days ago, the following lines are added in boost/multi_array.hpp (in order to increase the overload resolution of the constructor???). *************** *** 93,98 **** --- 93,102 ---- #ifdef BOOST_NO_FUNCTION_TEMPLATE_ORDERING , typename detail::multi_array::disable_non_sub_array<ExtentList>::type* = 0 #endif + , typename + boost::disable_if_c< + boost::is_same<ExtentList,multi_array>::value + >::type* = 0 ) : super_type((T*)initial_base_,extents) { boost::function_requires< However, it breaks e.g. SGI MIPSpro, since it does not support SFINAE. (boost/config/compiler/common_edg.hpp defines BOOST_NO_SFINAE.) I'm very happy, as a workaround, if the lines could be wrapped "#ifndef BOOST_NO_SFINAE", like #ifndef BOOST_NO_SFINAE , typename boost::disable_if_c< boost::is_same<ExtentList,multi_array>::value >::type* = 0 #endif Any better idea? Synge

2 1

RE: [boost] Re: method deduction (on vc?)
by Max Khesin 15 Jul '04

15 Jul '04

> Max Khesin <MKhesin(a)liquidnet.com> writes: > > > But not (from your phrasing) function members? > > I don't know about those; I haven't tried to find workarounds > for that. > > FWIW, designs that depend on member detection are often flawed from a > generic programming POV. You can get accidental conformance, and > especially if there's no way to explicitly say what the member means > (e.g. with a traits specialization), you'll be out-of-luck. Well, this is my intent, just for the record, (perhaps there are other techniques that apply): I want a generic dispatch function that accepts some "Message", makes it into a concrete class and dispatches it to the overloaded handler function: // A, B, C, ... derived from some Base template<class HandlerT> void dispatchMsg(HandlerT& h, Msg m) { if(m.getName()=="A") { h.onMsg(A(m)); }else if(m.getName()=="B") { h.onMsg(B(m)); } // etc } the handler class has to implement overloaded handler functions for the the classes it is interested in and (right now) a 'catch-all' handler for the Base& (to insure that the thing compiles). Ideally I would like to eliminate this requirement by detecting whether HandlerT has a onMsg(T&) and providing a no-op for that (via another level of indirection), some thing like: template<class HandlerT> void dispatchMsg(HandlerT& h, Msg m) { if(m.getName()=="A") { dispatcher<HAS_METH(h, void, onMsg, A&)>::dispatch(A(m)); }else if(m.getName()=="B") { dispatcher<HAS_METH(h, void, onMsg, B&)>::dispatch(A(m)); } // etc } This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

1 0

[preprocessor] Sun Studio 9 Early Access regressions
by Christopher Currie 15 Jul '04

15 Jul '04

Can anyone lend assistance in debugging the Sun regressions for Boost Preprocessor? The early access edition of the Studio 9 compiler is failing on BOOST_PP code that compiles just fine under earlier versions. The code that's failing appears to relate to the expansion (or lack thereof) of the macros that implement BOOST_PP_WHILE. I'm continuing to investigate, but since I'm unfamiliar with what the macros are *supposed* to do, I'm hoping someone can spot the trouble more quickly than I can. I've attached the preprocessed code from libs/preprocessor/test/control.cpp. Thanks in advance, Christopher -- Christopher Currie <codemonkey(a)gmail.com> #1 "/home/ccurrie/src/boost/libs/preprocessor/test/control.cpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/arithmetic/add.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/arithmetic/dec.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/config/config.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/arithmetic/inc.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/control/while.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/cat.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/debug/error.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/detail/auto_rec.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/control/iif.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/list/fold_left.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/control/while.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/list/detail/fold_left.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/control/expr_iif.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/list/adt.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/detail/is_binary.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/detail/check.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/logical/compl.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/tuple/eat.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/list/fold_right.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/control/while.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/list/detail/fold_right.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/list/reverse.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/logical/bitand.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/control/detail/while.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/logical/bool.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/tuple/elem.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/control.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/control/deduce_d.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/control/expr_if.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/control/if.hpp" #1 "/home/ccurrie/src/boost/libs/preprocessor/test/test.h" #1 "/opt/SUNWspro/prod/include/CC/std/cstdio" #1 "/usr/include/sys/feature_tests.h" #13 "/usr/include/sys/feature_tests.h" #pragma ident "@(#)feature_tests.h 1.18 99/07/26 SMI" #1 "/usr/include/sys/isa_defs.h" #9 "/usr/include/sys/isa_defs.h" #pragma ident "@(#)isa_defs.h 1.20 99/05/04 SMI" #158 extern "C" { #380 } #18 "/usr/include/sys/feature_tests.h" extern "C" { #181 } #1 "/usr/include/iso/stdio_iso.h" #32 "/usr/include/iso/stdio_iso.h" #pragma ident "@(#)stdio_iso.h 1.2 99/10/25 SMI" #1 "/usr/include/sys/va_list.h" #9 "/usr/include/sys/va_list.h" #pragma ident "@(#)va_list.h 1.12 99/05/04 SMI" #22 extern "C" { typedef void * __va_list ; } #1 "/usr/include/stdio_tag.h" #9 "/usr/include/stdio_tag.h" #pragma ident "@(#)stdio_tag.h 1.3 98/04/20 SMI" extern "C" { #21 typedef struct __FILE __FILE ; } #1 "/usr/include/stdio_impl.h" #9 "/usr/include/stdio_impl.h" #pragma ident "@(#)stdio_impl.h 1.8 99/06/10 SMI" #14 extern "C" { #22 typedef int ssize_t ; #38 struct __FILE { ssize_t _cnt ; unsigned char * _ptr ; unsigned char * _base ; unsigned char _flag ; unsigned char _file ; unsigned __orientation : 2 ; unsigned __ionolock : 1 ; unsigned __filler : 5 ; } ; } #49 "/usr/include/iso/stdio_iso.h" extern "C" { #59 typedef long long __longlong_t ; #70 namespace std { typedef __FILE FILE ; #83 typedef unsigned int size_t ; typedef long fpos_t ; } #147 extern __FILE __iob [ 20 ] ; #159 namespace std { extern int remove ( const char * ) ; extern int rename ( const char * , const char * ) ; extern FILE * tmpfile ( void ) ; extern char * tmpnam ( char * ) ; extern int fclose ( FILE * ) ; extern int fflush ( FILE * ) ; extern FILE * fopen ( const char * , const char * ) ; extern FILE * freopen ( const char * , const char * , FILE * ) ; extern void setbuf ( FILE * , char * ) ; extern int setvbuf ( FILE * , char * , int , size_t ) ; extern int fprintf ( FILE * , const char * , ... ) ; extern int fscanf ( FILE * , const char * , ... ) ; extern int printf ( const char * , ... ) ; extern int scanf ( const char * , ... ) ; extern int sprintf ( char * , const char * , ... ) ; extern int sscanf ( const char * , const char * , ... ) ; extern int vfprintf ( FILE * , const char * , __va_list ) ; extern int vprintf ( const char * , __va_list ) ; extern int vsprintf ( char * , const char * , __va_list ) ; extern int fgetc ( FILE * ) ; extern char * fgets ( char * , int , FILE * ) ; extern int fputc ( int , FILE * ) ; extern int fputs ( const char * , FILE * ) ; #203 extern char * gets ( char * ) ; extern int puts ( const char * ) ; extern int ungetc ( int , FILE * ) ; extern size_t fread ( void * , size_t , size_t , FILE * ) ; extern size_t fwrite ( const void * , size_t , size_t , FILE * ) ; extern int fgetpos ( FILE * , fpos_t * ) ; extern int fseek ( FILE * , long , int ) ; extern int fsetpos ( FILE * , const fpos_t * ) ; extern long ftell ( FILE * ) ; extern void rewind ( FILE * ) ; #219 extern void perror ( const char * ) ; extern int __filbuf ( FILE * ) ; extern int __flsbuf ( int , FILE * ) ; #278 } #288 namespace std { inline int getc ( FILE * _p ) { return ( -- _p -> _cnt < 0 ? __filbuf ( _p ) : ( int ) * _p -> _ptr ++ ) ; } inline int putc ( int _x , FILE * _p ) { return ( -- _p -> _cnt < 0 ? __flsbuf ( _x , _p ) : ( int ) ( * _p -> _ptr ++ = ( unsigned char ) _x ) ) ; } } #308 namespace std { inline int getchar ( ) { return getc ( ( & __iob [ 0 ] ) ) ; } inline int putchar ( int _x ) { return putc ( _x , ( & __iob [ 1 ] ) ) ; } } #319 namespace std { inline void clearerr ( FILE * _p ) { _p -> _flag &= ~ ( 0040 | 0020 ) ; } inline int feof ( FILE * _p ) { return _p -> _flag & 0020 ; } inline int ferror ( FILE * _p ) { return _p -> _flag & 0040 ; } } #336 } #25 "/home/ccurrie/src/boost/libs/preprocessor/test/test.h" namespace std { } using namespace std ; int main ( void ) { printf ( "pass " "11:06:52" ) ; return 0 ; } #20 "/home/ccurrie/src/boost/libs/preprocessor/test/control.cpp" typedef int test_20 [ ( ( ( 0 ) == 0 ) == 1 ) ? 1 : - 1 ] ; typedef int test_21 [ ( ( 1 == 1 ) == 1 ) ? 1 : - 1 ] ; typedef int test_23 [ ( ( 1 == 1 ) == 1 ) ? 1 : - 1 ] ; typedef int test_24 [ ( ( ( 0 ) == 0 ) == 1 ) ? 1 : - 1 ] ; typedef int test_26 [ ( ( 0 == 0 ) == 1 ) ? 1 : - 1 ] ; typedef int test_27 [ ( ( 1 == 1 ) == 1 ) ? 1 : - 1 ] ; typedef int test_29 [ ( ( 0 == 0 ) == 1 ) ? 1 : - 1 ] ; typedef int test_30 [ ( ( 1 == 1 ) == 1 ) ? 1 : - 1 ] ; typedef int test_35 [ ( ( BOOST_PP_WHILE_BOOST_PP_IIF_BOOST_PP_BITAND_1 1 ( BOOST_PP_NODE_64 , BOOST_PP_NODE_192 ) ( BOOST_PP_WHILE_P #35 ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P #35 ) ( PRED , OP_1 , 50 ) == 0 ) == 1 ) ? 1 : - 1 ] ; typedef int test_40 [ ( ( BOOST_PP_WHILE_BOOST_PP_IIF_BOOST_PP_BITAND_1 1 ( BOOST_PP_NODE_64 , BOOST_PP_NODE_192 ) ( BOOST_PP_WHILE_P #40 ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P #40 ) ( PRED , OP_3 , 10 ) == 0 ) == 1 ) ? 1 : - 1 ] ; typedef int test_41 [ ( ( BOOST_PP_WHILE_BOOST_PP_IIF_BOOST_PP_BITAND_1 1 ( BOOST_PP_NODE_64 , BOOST_PP_NODE_192 ) ( BOOST_PP_WHILE_P #41 ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P #41 ) ( PRED , OP_3 , 10 ) == 0 ) == 1 ) ? 1 : - 1 ] ;

3 5

Re:Re: [boost] serialization test failure on darwin
by Robert Ramey 15 Jul '04

15 Jul '04

Marshall Clow wrote: > What I see is that the serialization library defines "std::wcslen" in > "wcslen.h", > even though there's a perfectly good one already available. This is > conditionalized > off of BOOST_NO_CWCHAR, which leads me to think that this flag is > wrong in the darwin config. > So, I moved it so that it is only set when building on GCC 2.95.x. Interesting. I examined the config files for macos and was left confused. It seemed to me that gcc 3.3 left BOOST_NO_CWHAR undefined while macos overrode that with a define. But then the regex test runs a config test whose results suggest that BOOST_NO_CWCHAR is not defined so I'm left absolutely and totally confused. On top of this I now have some doubts about my inclusion of my own definition of wcslen which I now suspect may have been the wrong response to some other question. I'm not sure if Darwin and macos are the same thing. So your observations and experiments are very opportune. I want to take a little time to check my usage/definition of wcslen ('til tomorrow). If you want to double check the config for gcc/macos/Darwin that would be good as well. I will also check the test results and make any other indicated corrections as these issues are orthogonal to this current wcslen one. Thanks for all your help. Robert Ramey

2 1

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 15 Jul '04

15 Jul '04

Mike, IMHO your comments below justifying different mutex types make sense. However, I feel that you look at the problem from the *implementor* point of view that is drastically different from the view of the library *user*. And I feel that the interface (representing convenience, flexibility, usability, etc.) is the first thing that a library will be judged by. I feel that for the user having different types of mutexes is inconvenient and unnecessary restricting. It is because when I create a mutex, I identify a resource that I want to serialize access to (it's a strategic decision in military terms :-) ). However, *how* I serialize the access (via blocking lock or try/timed locks) is not generally known at the time and will be defined on the case-by-case basis (when I'll be actually creating appropriate locks -- it's a tactical decision). A typical and very basic application I am working on discriminates two threads (and, therefore the appropriate mutex) -- the first always applies a blocking lock (scoped_lock) and the other thread only steps in through the successful try-lock. Having additional (and maybe unused) data in a mutex does not seem like a huge problem (as long as it does not impose performance penalties) -- memory is cheap and mutexes are not usually created in huge numbers. More so, I believe in boost there are techniques/classes minimizing waste. Best, V. > > Now that we got rid of the excess locks, how about doing the same with > the > > mutexes? > > I had considered this, but there does seem to be some benefit in having > separate mutex types, which is what I assume led to there being three > mutex types and three lock types in the original design. You've noted > these reasons below, but I'll reiterate: > > * On pthreads, the timed mutex requires an additional data member, > (condition variable) to handle cases when pthreads_timedlock isn't > supported. > > * On WinNT, the timed mutex operations require a win32 mutex object, > while the mutex and try mutex can use a win32 critical section. > > * On Win9x, the timed mutex and try mutex operations require a win32 > mutex object, while the mutex can use a win32 critical section. > > In other words, on the most widely-used platforms, collapsing the mutex > types into one imposes some penalty (larger mutex object or more limited > implementation options) on users. Also (I ask, not as a hypothetical > question, but as a request for information): is there another platform > where combining the mutex types incurs a similar or worse penalty?

2 1