- Boost - lists.boost.org

Foreshadowing a coming review
by John Phillips 12 Jan '07

12 Jan '07

Possibly because of the recent holidays, there hasn't been much reviewing activity recently. The schedule says the last one ended in mid-November. However, I want to remind everyone that this is changing soon. The Accumulators library review is coming at the end of the month. Since I know I have occassionally wanted to participate in a review and then found that I just ddidn't have the time for it when the review period started, as the manager for this review I want to encourage everyone to take a look early, and avoid the last minute time crunch. The review will begin on January 29. The real announcement will come then. I hope many of you can make the time to contribute. John Phillips

1 0

Re: [boost] [Threads] uncoditional scoped lock?
by Sohail Somani 12 Jan '07

12 Jan '07

> [mailto:boost-bounces@lists.boost.org] On Behalf Of Dmitry Ivankov > > By the way, what about extending barrier so that it can use > any functor not > only waiting_threads == m_threshold? > At least > timed_barrier, which unblocks when (waiting_threads == m_threshold || > time_since_first_wait > m_time_threshold), > and maybe unblocks in destructor. > > So it'll implement scenario: do the work in groups, i.e. not > very often. > That can be for example some time-expensive background cached work. Thanks to the GP for the pointer to barrier. +1 for any functor from me anyway. The case I used was just an example. Barrier+functor would be higher-level, more obvious, and I'd think less prone to errors. Sohail

1 0

Re: [boost] [Threads] uncoditional scoped lock?
by Sohail Somani 12 Jan '07

12 Jan '07

> [mailto:boost-bounces@lists.boost.org] On Behalf Of Dmitry Ivankov > > But just wait in threads is bad, because of spurious wake > ups. It should be > like > > while (!::we_can_start) > g_some_cond.wait(condition_lock); > > and > > ::we_can_start = true; > condition_lock.notify_all(); Yes, I do need to read my OS dev textbook again which tried to hammer this in. Is there some way to encapsulate this? Bad idea? Thanks, Sohail

1 0

[graph] leda_graph.hpp - Succ_Adj_Edge etc. undocumented in LEDA?
by Jens Müller 12 Jan '07

12 Jan '07

Are functions like Succ_Adj_Edge inofficial? I googled for them and can't find any occurence in the official LEDA documentation. The "official way" seem to be member functions of the GRAPH class ... Obviously, in that case a reference to the graph would have to be stored in the iterator as well, so I see the advantage of the current solution. But shouldn't we stick to official interfaces? I stumbled over this while looking how to add support for the EdgeListGraph concept in the LEDA graph adapter ...

2 3

[Boost-bugs] [ boost-Support Requests-1634278 ] memory pattern question
by SourceForge.net 12 Jan '07

12 Jan '07

Support Requests item #1634278, was opened at 2007-01-12 10:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1634278&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: memory pattern question Initial Comment: Hi, My team developed an application in C++. The application's working set increases steadily. All leaks we could track we corrected. The last remaining leak is a difficult one. The reason I post this message here is to see if someone has an idea of what this data structure could be or a pointer to where I could look. We use template stuff in the code (trees, sets, etc etc). We look at the memory by hexanalyzing a forced core. (this is a linux app). The pattern is inside blocks of malloce'd space and these blocks appear larger and larger with similar content. The patter is as follows: int char [4] void *; void * Exactly 16 bytes, the int is 1 or 2 for the most part but I have seen 0xFFFFFFFF at times. The char at times has character but never no more than 3 followed by \0. The last two seem to be real pointers and at time 0x20 and 0x40 from each other. At first glance it looks like a tree entry but not sure. Any ideas ? Thanks David De La Rosa delarosa(a)ilstechnology.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1634278&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] [Threads] uncoditional scoped lock?
by Sohail Somani 12 Jan '07

12 Jan '07

I should have mentioned that one can't use wait(mtx,pred) because this needs to be used in the signalling thread. It might be better to have this as a scoped_lock constructor? Anyway... > -----Original Message----- > From: Sohail Somani > Sent: Friday, January 12, 2007 10:39 AM > To: 'boost(a)lists.boost.org' > Subject: [Threads] uncoditional scoped lock? > > Hi, > > Somewhat longer-than-normal-noise follows :) > > Consider the following pseudo-code which has a race condition: > > condition g_some_cond; > mutex g_condition_mtx; > > void thread_fn() > { > { > ... // get lock > g_some_cond.wait(condition_lock); > } > // do work > } > > void main_thread() > { > thread_group grp; > // Start all threads and have them wait on the condition > for(i in [0,N)) grp.create_thread(&thread_fn); > > { > ... // get lock > g_some_cond.notify_all(); // let threads continue > } > } > > The race condition is of course that it is possible that not > all threads actually start waiting on the condition before > notify_all() is called. In this case, it is possible to solve > the race condition in two ways: > > 1) Have the last thread that reaches the condition wait, > signal to the main thread > 2) Have the main thread checking the condition before notify_all() > > I don't really like the first case because it requires > bi-directional signalling between the threads. Though in my > ignorance, I really do consider it the correct solution. The > second solution would look something like this: > > while(true) > { > scoped_lock cond_lock(g_condition_mtx); > // .num_waiting_threads() is made up > if(N_EXPECTED_THREADS==g_some_cond.num_waiting_threads()){break;} > // release lock > } > > Should the second pattern be encapsulated in the condition > object somehow? It is almost like timed_wait(mtx,xt,pred) but > there is no timeout. So maybe untimed_wait()? Is there > another way to do this? > > Thanks for your eyes! > > Sohail

2 1

[iterator] Proposal for inclusion of a csv_ostream_iterator class.
by Emre Turkay 12 Jan '07

12 Jan '07

Hi folks, Attached is the csv_ostream_iterator class, I frequently use. I think it could be incorporated into the boost.iterator library (if there is no such thing somewhere in the standart or in some boost library so far.) What it does is very similar to the std::ostream_iterator, the only difference is that it does not put a delimiter after the last element inserted. Such as when we write an integer container to a stream with a comma delimiter, we get something like this: { 1, 7, 12, 5, 8, } however by using this class the last delimiter is gone { 1, 7, 12, 5, 8 } which is mostly the intended behavior. It can be used for textual data generation (for correct CSVs and good looking XMLs) including code generation. Note: Works with gcc-4.x, may needs to be modified to be portable. Thanks, Emre Turkay

2 1

Re: [boost] Regressions in your Boost libraries as of 2007-01-12 [RC_1_34_0]
by Jeremy Siek 12 Jan '07

12 Jan '07

Hi Doug, Are there any OSL machines with the below compilers installed that I could use to resolve these issues? Best regards, Jeremy On Jan 12, 2007, at 10:00 AM, Douglas Gregor wrote: > You are receiving this report because one or more of the libraries you > maintain has regression test failures that are not accounted for. > A full version of the report is sent to the Boost developer's mailing > list. > > Detailed report: > http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/ > developer/issues.html > > There are failures in these libraries you maintain: > concept_check (15) > > |concept_check| > class_concept_fail_expected: borland-5.6.4 borland-5.8.2 > borland-5.8.2 msvc-6.5 msvc-6.5 msvc-7.0 > stl_concept_covering: borland-5.8.2 borland-5.8.2 gcc-3.3.6 > gcc-3.4.5_linux gcc-3.4.5_linux_x86_64 gcc-4.0.3_linux > gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc ______________________________________ Jeremy Siek <jeremy.siek(a)colorado.edu> http://www.cs.colorado.edu/~siek/ Visiting Assistant Professor Department of Computer Science University of Colorado at Boulder

1 0

[Report] 20 regressions on RC_1_34_0
by Douglas Gregor 12 Jan '07

12 Jan '07

Boost Regression test failures Report time: 2007-01-12T11:01:01Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… 20 failures in 5 libraries concept_check (15) date_time (1) regex (1) test (2) utility (1) |concept_check| class_concept_fail_expected: borland-5.6.4 borland-5.8.2 borland-5.8.2 msvc-6.5 msvc-6.5 msvc-7.0 stl_concept_covering: borland-5.8.2 borland-5.8.2 gcc-3.3.6 gcc-3.4.5_linux gcc-3.4.5_linux_x86_64 gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc |date_time| testgenerators: qcc-3.3.5_gpp |regex| regex_regress_threaded: msvc-6.5 |test| prg_exec_fail2: darwin-4.0.1 prg_exec_fail3: cw-9.4 |utility| operators_test: gcc-3.4.5_linux_x86_64

1 0

Boost.Build does not recognize .v2 less Jamfile s
by Roland Schwarz 12 Jan '07

12 Jan '07

I might have missed something in the Discussion, but isn't the v2 expected to work on Jamfile _and_ Jamfile.v2 ? If I actually rename the file Jamfile.v2 to Jamfile the build from boost root does not work anymore. Maybe a hint: the library does not show up in bjam --show-libraries. Thank you for attention, Roland

2 4