Re: [boost] boost::threads - a few more questions..

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-06-19 08:41:37

----- Original Message -----
From: "Peter" <piotrus_at_[hidden]>
Newsgroups: gmane.comp.lib.boost.devel
To: <boost_at_[hidden]>
Sent: Tuesday, June 18, 2002 6:46 PM
Subject: [boost] boost::threads - a few more questions..

> I have a few more questions regarding boost::threads:
>
> 1) Is is at all possible to get a return value from a function which was
> passed into a thread - for example after calling thread.join() ??

Wrap the "return value" up in the function object and query it after the
join().  This allows you to return any data type.  You'll have to remember
that the function object is passed by value, so you'll actually want to put
a reference/pointer to the returned data in the function object.  Rough
example:

struct MyFunctionObject
{
   MyFunctionObject(int& ret) : ret(ret) { }
   void operator()() { ret = 99; }
   int& ret;
};

void start_thread()
{
   int ret = 0;
   boost::thread thread(MyFunctionObject(ret));
   thread.join();
   assert(ret == 99);
}

> 2) Assuming that I create a thread from within another thread ( for
exaple:
> from within the "main" thread -  main()); is there a mechanism for that
> newly created thread to notify my "main" thread that it has finished
> execution?? Is there some sort of library (I am looking for something
> platform independent) which would allow me to do that??

I'm not sure I understand the question.  Usually join() will work for this.
If you need something else you should be able to build what ever you need
here using a boolean flag, a mutex and a condition.  Maybe if you gave a
more concrete use case I could give you a better answer here.

> 3) I would lie to run two threads in a client application. One would be
> responsible for receiving and the other for sending data. The threads
would
> basically run in infinite loops.  Both sending and receiving would be done
> to/from the SAME socket. My question is: Do i still have to lock the mutex
> during each opperation?? I have been doing a LOT of testing WITHOUT
locking
> it and have not had my program crash (yet). Is that because the kernel
> (running win2000 and using the winsock API) is somehow dealing with all
the
> overhead of locking/unlocking the socket, or have I just been lucky??

The socket is a shared resource, so yes, you'd have to use a mutex here.
Any behavior you see with out using a mutex is just what your
platform/compiler chose to do (today) in this case, since what you're doing
invokes undefined behavior.

Bill Kempf