Re: a really simple C++ abstraction around pthread_t...
Responding late, it was a rough week...
Chris M. Thomasson wrote:
"Ulrich Eckhardt" <doomster@knuut.de> wrote in message
news:6n37ijFjjf0hU1@mid.uni-berlin.de...
Chris M. Thomasson wrote:
[C++ thread baseclass with virtual run() function]
I personally like this technique better than Boost. I find it more
straight forward and perhaps more object oriented, the RAII nature of
the `active' helper class does not hurt either. Also, I really do think
its more "efficient" than Boost in the way it creates threads because it
does not copy anything...
There are two things that strike me here:
1. You mention "object oriented" as if that was a goal, but it isn't.
Rather, it is a means to achieve something, and the question is always
valid whether its use is justified. Java's decision to force an OO design
on you and then inviting other paradigms back in through the backdoor is
the prime example for misunderstood OO. Wrapping a thread into a class
the way you do it is another IMHO, ill explain below.
2. What exactly is the problem with the copying? I mean you're starting a
thread, which isn't actually a cheap operation either. Further, if you
want, you can optimise that by using transfer of ownership (auto_ptr) or
shared ownership (shared_ptr) in case you need. Boost doesn't make it
necessary to copy anything either (except under the hood it does some
dynamic allocation), but also allows you to chose if you want. However,
copying and thus avoiding shared data is the safer default, because any
shared data access requires care.
[...]
If find it unfortunate to be forced to use an smart pointers and
dynamically created objects just to be able to pass common shared data to
a thread. I am still not convinced that treating a thread as an object is
a bad thing... For instance...
How would I be able to create the following fully compliable program
(please refer to the section of code under the "Simple Example" heading,
the rest is simple impl detail for pthread abstraction) using Boost
threads. The easy way to find the example program is to go to the end of
the entire program, and start moving up until you hit the "Simple Example"
comment...
If I get your code right, this program is creating two threads, each of
which models a person's behaviour. The main thread then asks them questions
which are stored in a queue to be handled asynchronously and prints the
answers which are received from another queue. Is that right?
Now, how would I rather design this? Firstly, I would define the behaviour
of the persons in a class. This class would be completely ignorant of any
threading going on in the background and only model the behaviour.
Then, I would create a type that combines a queue with a condition and a
mutex. This could then be used to communicate between threads in a safe
way. This would be pretty much the same as your version, both
pthread_cond_t and pthread_mutex_t translate easily to boost::mutex and
boost::condition.
Now, things get a bit more complicated, because first some questions need to
be answered. The first one is what the code should do in case of failures.
What happens if one person object fails to answer a question? What if
answering takes too long? What if the thread where the answers are
generated is terminated due to some error? What if the invoking thread
fails to queue a request, e.g. due to running out of memory?
The second question to answer is what kind of communication you are actually
modelling here. In the example, it seems as if you were making a request
and then receiving the response to that request, but that isn't actually
completely true. Rather, the code is sending a message and receiving a
message, but there is no correlation between the sent and received message.
If this correlation is required, I would actually return a cookie when I
make a request and retrieve the answer via that cookie.
In any case, you can write an equivalent program using Boost.Thread. If you
want, you can wrap stuff into a class, e.g. like this:
struct active_person
{
explicit active_person(queue& out_):
out(out_),
th( bind( &handle_requests, this))
{}
~active_person()
{ th.join(); }
void push_question( std::string const& str)
{ in.push(str); }
std::string pop_answer()
{ return out.pop(); }
private:
void handle_requests()
{
while(true)
{
std::string question = in.pop();
if(question=="QUIT")
return;
out.push(p.ask(question));
}
}
queue in;
queue& out;
person p;
// note: this one must come last, because its initialisation
// starts a thread using this object.
boost::thread th;
};
You could also write a simple function:
void async_quiz( person& p, queue& questions, queue& answers)
{
while(true)
{
std::string question = questions.pop();
if(question=="QUIT")
return;
answers.push(p.ask(question));
}
}
queue questions, answers;
person amy("amy");
thread th(bind( &async_quiz, ref(amy),
ref(questions), ref(answers)));
.... // ask questions
th.join();
Note the use of ref() to avoid the default copying of the argument. Using
pointers would work, too, but I find it ugly.
In any case, this is probably not something I would write that way. The
point is that I can not force a thread to shut down or handle a request. I
can ask it to and maybe wait for it (possibly infinitely), but I can not
force it. So, if there is any chance for failure, both on the grounds of
request handling or the request handling mechanism in general, this
approach becomes unusable. Therefore, I rather prepare for the case that a
thread becomes unresponsive by allowing it to run detached from the local
stack.
Writing about that, there is one thing that came somehow as a revelation to
me, and that was the Erlang programming language. It has concurrency built
in and its threads (called processes) communicate using messages. Using a
similar approach in C++ allows writing very clean programs that don't
suffer lock contention. In any case, I suggest taking a look at Erlang just
for the paradigms, I found some really good ideas to steal from there. ;)
#define when_xx(mp_pred, mp_line) \
monitor::lock_guard lock_guard_##mp_line(*this); \
monitor::signal_guard signal_guard_##mp_line(*this); \
while (! (mp_pred)) this->wait();
#define when_x(mp_pred, mp_line) when_xx(mp_pred, mp_line)
#define when(mp_pred) when_x(mp_pred, __LINE__)
Just one note on this one: When I read your example, I stumbled over the use
of a 'when' keyword where I would expect an 'if'. I find this here really
bad C++ for several reasons:
1. Macros should be UPPERCASE_ONLY. That way, people see that it's a macro
and they know that it may or may not behave like a function. It simply
avoids surprises.
2. It is used in a way that breaks its integration into the control flow
syntax. Just imagine that I would use it in the context of an 'if'
expression:
if(something)
when(some_condition)
do_something_else();
I'd rather write it like this:
if(something) {
LOCK_AND_WAIT_CONDITION(some_condition);
do_something_else();
}
Firstly, you see that these are separate statements and this then
automatically leads to you adding the necessary curly braces.
Please correct me if I am wrong, but Boost would force me to dynamically
create the `person::queue request' object in main right?
No. The argument when starting a thread is something that can be called,
like a function or functor, that's all. This thing is then copied before it
is used by the newly started thread. Typically, this thing is a function
bound to its context arguments using Boost.Bind or Lambda. If you want, you
can make this a simple structure containing a few pointers or references,
i.e. something dead easy to copy.
cheers
Uli