- Boost-users - lists.preview.boost.org

Re: Extending the boost::thread class
by arno.schaefer＠sqs.de 14 Oct '04

14 Oct '04

> For what it's worth, William Kempf began an implementation of thread > priorities and an exception-based thread cancellation scheme on the > thread_dev branch before he stopped working on Boost.Threads. If it's > completed enough (I haven't examined it closely enough yet to tell), > I hope to move it into the a Boost release after the upcoming 1.32. > That won't help you right now, however. I feel sorry about that, but perhaps it is possible to get a look to the actual state? Arno

2 1

Boost & VC2005 (Whidbey)
by S.I.M. van Keulen 14 Oct '04

14 Oct '04

Hi all, recently I started 'porting' some projects to 64 bit Windows (AMD) using Visual Studio 2005. I noticed that the Compiler had trouble with Boost. Searching the net didn't provide much helpfull information. I wondered if any of you had tried anything with Boost and VC2005/Whidbey compilers. Or if any of you could direct me to some information source on the net. Thank you! Serge van Keulen

3 3

Re: "smart list" container?
by David Jones 13 Oct '04

13 Oct '04

"Caleb Epstein" <caleb.epstein(a)gmail.com> wrote in message news:<989aceac041012063240b6aa3(a)mail.gmail.com>... > On Mon, 11 Oct 2004 10:19:54 -0600, David M. Jones <djones(a)keymark.com> wrote: > > - The container itself would act more or less identically to std::list; > > - The iterators on the container would act like boost::weak_ptr in that they > > would know that they are invalid when the list element that they point to is > > removed. > > Can't you just do this with a std::list<boost::shared_ptr>? You can > convert the *iterators to weak_ptrs as needed. Or am I missing > something? There are a couple of reasons that std::list<boost::shared_ptr> is less than ideal. First, using the algorithms becomes cumbersome/annoying. Instead of being able to write std::list<boost::shared_ptr<int> > lst; // ... Populate the list int i; // ... Set the value of i std::list<boost::shared_ptr<int> >::iterator = std::find(lst.begin(), lst.end(), i); I instead need to create a function object to represent a boost::shared_ptr<int> having the desired value and then use find_if(). Second, I would lose the ability to store iterators and then check them later for validity. Suppose that I have a std::list<boost::shared_ptr<int> > named lst and I have two std::list<boost::shared_ptr<int> >::iterator objects it1 and it2 that happen to reference the same node in the list. If I call lst.erase(it1) then it2 also becomes invalid. If I call boost::weak_ptr<int>(*it2) I get an error because I cannot dereference the iterator because it is already invalid. This is how std::list objects are supposed to work but what I want to be able to do is now call something like it2.expired() to determine that the node being refered to by it2 is not invalid/expired/removed. One way to get around this is to store boost::weak_ptr objects derived from std::list<boost::shared_ptr>::iterator objects instead of storing it1 and it2 directly. But then I lose the advantage of having stored iterators: I cannot (after checking for expiration and being at the end of the list) call operator++() to move the iterator forward. Fundamentally, I don't want to be storing a "list of nodes of shared pointers of objects" but a "list of nodes of objects whose pointers to each other are shared pointers". And I want the iterators to be weak pointers to the nodes. Potentially a way to do this would be to write a custom allocator my_alloc that declares typedef boost::shared_ptr pointer; and then create a std::list<T, my_alloc<T> > This works because std::list uses the allocator rebinding mechanism to call my_alloc<node<T> > rather than my_alloc<T>. (In fact, my_alloc<T> is never used to allocate anything in std::list<T>!) However, there is a problem because the interface (concept a la Austern) of boost::shared_ptr is different than that of a regular pointer. So when the std::list code tries to call _Myhead = 0; I get a compiler error. (I am using MSVC 7.1: although this particular error may be STL implementation dependent, I do believe that the problem I am describing will occur with any STL implementation.) But I digress... The question of why the boost::shared_ptr interface/concept does not conform to that of a normal pointer is probably a topic for a separate posting.

2 1

RE: [Boost-users] Extending the boost::thread class
by Foster, Gareth 13 Oct '04

13 Oct '04

Could you make it something like "enum { eLow, eNormal, eHight }; myThread.priority(eHigh);"? Maybe something non specific would be do-able, and it might still be useful to those who aren't after lots of control? Not that I am well clued up, just a thought. Cheers! Gaz -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Ben Hutchings Sent: 13 October 2004 17:45 To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] Extending the boost::thread class arno.schaefer(a)sqs.de wrote: > Hi all, > I want to use the boost thread library as a base for my multiplatform > thread class. After I have studied the documentation I recognize that > there are not all things available at the moment what I need, so I try > to find out what is the best way to start my implementation. What I > need, is to implement the following additional methods: suspend, resume, > stop (or terminate), set_priority, get_priority, get_state and I want to > have the possibility to create threads in a suspend mode. <snip> Why do you think you want suspend, resume and terminate? There are very few safe uses for these operations, and programs that use them tend to suffer from data corruption and/or deadlocks. It would be fairly easy to add support for priority settings to Boost.Thread, but since priority values are only meaningful in the context of a scheduling policy and policies vary between operating systems it would be hard to provide a genuinely portable priority system. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Extending the boost::thread class
by arno.schaefer＠sqs.de 13 Oct '04

13 Oct '04

Hi all, I want to use the boost thread library as a base for my multiplatform thread class. After I have studied the documentation I recognize that there are not all things available at the moment what I need, so I try to find out what is the best way to start my implementation. What I need, is to implement the following additional methods: suspend, resume, stop (or terminate), set_priority, get_priority, get_state and I want to have the possibility to create threads in a suspend mode. I want to use the boost thread as is and extend the needed features in my own class, but it seems so that their is at the moment no legal way to get the internal thread resource from a created thread, so that I can implement the missing and perhaps not portable features by my own? So what is the prefered way to extend the thread class? Is their a reasonable way to do it or should I build my own class from scratch? many thanks for any input and guess, regards Arno

3 2

about boost graph library -- subgraph
by qyang＠cs.ucr.edu 12 Oct '04

12 Oct '04

Hi, I am new here. I recently downloaded the boost library from www.boost.org. I need to use the "subgraph" function in the library. I tried to run the example file "subgraph.cpp", but the running result was different from what was given in the file. Below is my running result and sample output: //my result: G0: 0 --> 1 1 --> 2 3 2 --> 5 3 --> 4 --> 1 5 5 --> 3 0(0,1) 1(1,2) 2(1,3) 6(2,5) 3(4,1) 4(4,5) 5(5,3) G1: 0 --> 2 1 --> 2 2 --> 6(0,2) 4(1,2) G2: 0 --> 1 1 --> 0(0,1) //sample output G0: 0 --> 1 1 --> 2 3 2 --> 5 3 --> 4 --> 1 5 5 --> 3 0(0,1) 1(1,2) 2(1,3) 6(2,5) 3(4,1) 4(4,5) 5(5,3) G1: 2 --> 5 4 --> 5 5 --> 6(2,5) 4(4,5) G2: 0 --> 1 1 --> 0(0,1) //====================================================== Basically what happened was that the vertex indices of the subgraph G1 in my output are child's local indices, however, the vertex indices of the subgraph G1 in the sample output is parent's global indices. Can somebody explain this? Is it a bug in the boost code? Thanks very much, Qiaofeng

2 1

Thread library Win32 static linking for MSVC 2003 release?
by Emilio Schapira 12 Oct '04

12 Oct '04

Does anybody know when will be the next release of Boost that has the threads library fixed such that it is possible to link statically in win32 platforms compiling with MSVC++ 2003? I have read that it will be fixed for the next release. Also, how stable is the current version of the library in the CVS repository? I was browsing through it and it seems to have been fixed. Anybody has experiences with it? Thanks, Emilio.

2 2

"Compiler threading support not turned on" error
by Glen Simmons 12 Oct '04

12 Oct '04

I'm attempting to use Boost.threads on Mac OS X 10.3 and am getting the error "Compiler threading support is not turned on" when trying to compile. I'm using Xcode, which is Apple's IDE, so I'm not sure what to do when the error text helpfully suggests I set the correct command line option. As far as I know, there's nothing extra that you have to do to enable threading support in the compiler. I've written multi-threaded apps using pthreads and never had to deal with command line options. Any suggestions? Thanks, Glen Simmons

4 9

"smart list" container?
by David M. Jones 12 Oct '04

12 Oct '04

Hello, I have run into a situation where the following std::list-like container would be useful. - The container itself would act more or less identically to std::list; - The iterators on the container would act like boost::weak_ptr in that they would know that they are invalid when the list element that they point to is removed. Does anyone know of such a container in any of the boost libraries, in another library or a way to accomplish the task using other means (such as iterator adaptors)? I looked at the newly proposed "smart containers" library, but it seems to be solving a different problem despite the similarity with the name I am using to describe what I want. Thanks in advance, David M. Jones

2 1

two boost.threads taking much longer than one
by Andrew Chapman 11 Oct '04

11 Oct '04

Hi everyone, I've got an operation which takes 14 seconds on a single thread, but is taking up to 45 seconds when running via two boost.threads on a dual proc machine (2x 3ghz Xeons, Fedora Core 1). The thread functor objects are being passed a lot of references (about 20) to some very large std::vectors. One thread always reads/writes from the start of the vectors to their midpoint, and the second thread from (midpoint+1) to the end of the vectors. The only thing I can think of is that the threads are taking a long time to fork and get running, perhaps moving a lot of stack data around or something? When I look at the output of 'top' with threads displayed, I see the two threads appear, but they only use about 50-60% CPU utilization each. The system monitor shows mostly red (Kernel) as opposed to blue (User). Any ideas? -- Andrew Chapman Senior Technical Director - Framestore CFC

3 3