threads - basic introduction
looking through the boost.threads doc and there doesn't seem to be any "getting started" guide like entry. I often find these are easier to read and get to know the library a little bit before hitting the reference. Is there any out there somewhere?
--- Noah Roberts wrote:
looking through the boost.threads doc and there doesn't seem to be any "getting started" guide like entry. I often find these are easier to read and get to know the library a little bit before hitting the reference.
Is there any out there somewhere?
I found a C++ multithreading tutorial at <http://paulbridger.net/ > featuring Boost.Threads that might be worth looking at. Cromwell D. Enage ____________________________________________________________________________________ Never Miss an Email Stay connected with Yahoo! Mail on your mobile. Get started! http://mobile.yahoo.com/services?promote=mail
On 2/14/07, Noah Roberts <roberts.noah@gmail.com> wrote:
looking through the boost.threads doc and there doesn't seem to be any "getting started" guide like entry. I often find these are easier to read and get to know the library a little bit before hitting the reference.
Is there any out there somewhere?
There are a number of examples with some limited explanations at http://www.ddj.com/184401518 ~ Scott McMurray
Ok, thank you I will look at those resources. I also purchased an account with the ACM digital library so have access to many of the sources cited in the boost doc. One question I do have though. I am creating a functor object like so (ignore the CLI crap, it isn't relevant): class connection_thread_proc { gcroot<TcpListener ^> server; boost::shared_ptr<Listener> listener; public: connection_thread_proc(boost::shared_ptr<Listener> const& l, TcpListener ^ t) : server(t), listener(l) {} void operator() () { listener->run(server); } }; Now later I do something like so: void start_new_connection() { ... boost::thread connection_thread(connection_thread_proc(l,s)); } Originally I assumed that there would be problems with this since my thread object goes out of scope so I figure the connection_thread_proc it holds should be destroyed along with it...and with it important objects like the listener and the tcp connection. So I was working on this convoluted way to store threads and check their state...which boost doesn't support out of the box it looks like and I was going to have to add yet another wrapper to the pile...so I decided to try and see if it did indeed explode and it doesn't. The question is, am I looking at undefined behavior that happens to work correctly or is this by design? I would like to trust that this will continue working as I add behaviors.
Noah Roberts wrote:
void start_new_connection() { ... boost::thread connection_thread(connection_thread_proc(l,s)); }
Originally I assumed that there would be problems with this since my thread object goes out of scope so I figure the connection_thread_proc it holds should be destroyed along with it...and with it important objects like the listener and the tcp connection. So I was working on this convoluted way to store threads and check their state...which boost doesn't support out of the box it looks like and I was going to have to add yet another wrapper to the pile...so I decided to try and see if it did indeed explode and it doesn't.
The question is, am I looking at undefined behavior that happens to work correctly or is this by design?
It works by design. The constructor of boost::thread makes a private copy of the function object and keeps it alive until its operator() returns. The boost::thread object itself is irrelevant, the function object is part of the thread state block kept by the newly spawned thread. You can use boost::bind( &Listener::run, l, s ) instead of writing a function object by hand, although I don't know how it will react to your ^ thingies. :-)
Peter Dimov wrote:
You can use boost::bind( &Listener::run, l, s ) instead of writing a function object by hand, although I don't know how it will react to your ^ thingies. :-)
Badly. Very badly. It's probably as simple as boost::function not having any specializations for CLI reference types but I'm not going to try and figure out how to make them. I'm actually going to work toward weeding out all CLI crap and using C++. Unfortunately I'm working with a COM object that isn't behaving too well apparently and I'm no expert with COM. But that's neither here nor there...there are a few boost things that can't handle CLI types, which is not at all surprising. boost::function is one of those things, the output is about a mile long with a big screw you at the end.
participants (4)
-
Cromwell Enage -
me22 -
Noah Roberts -
Peter Dimov