Subj : Re: Thoughts about threads in C++
To   : comp.programming.threads
From : Arash Partow
Date : Thu May 26 2005 07:15 pm

Hi Maciej,

I would like to thank you for your comments on the library. They are
helpful, though I would like to clarify some points.

>> 1. You use explicit lock and unlock calls in your example code. This is
>> not really C++.

Threading is not really C++ either - or at least until someone defines
it within the standard. So in theory what one does could be
interpreted either way. that said I have not seen a C++ guru of high
calibre get up on the podium and say so and so way is the right way to
do this and the other way is wrong. one of the beauties of c++ is that
there are many of ways to do the same thing. My way may not be the
best way - but nonetheless its a laymen's attempt at some way.

>> 2. The POSIXThread base class is copyable, but its copy constructor and
>> assignment operator do nothing, not even copy the thread id (so the
>> comparison operators are broken). You also use copyable derived thread
>> classes in one of the example (you put them into the vector). I'm not
>> sure whether this is really what you want to do (for example: can I join
>> the copy of the original thread?).

Yeah i know about that, I have to update the code with some
modifications I've made over the past 6 months. Its getting
there though.

You can set a thread to be join-able by setting the right parameter
when you call start(), the join param is set to false, but if set
to true another thread if it has a reference to the thread in question
can call the join() routine which will essentially put it to sleep
until the other thread is finished.


>> 3. The class POSIXScopeMutex makes no sense at all - how do you want to
>> use it from multiple threads?

not everything can be used everywhere, the scope mutex is one of these
cases. Its purpose is two fold.

1.) to make mutex oriented code look cleaner

2.) to ensure any additions to the code which is meant to be mutexed
wont effect the synchronos of the code.


Basically you pass an reference of a mutex to the scope mutex. you
make sure the scope mutex is defined as being one of the first things
in the piece of code you wanted to be locked down. the mutex lock gets
called in the constructor of the mutex and the unlock gets called in
the destructor of the mutex (its a pretty well known pattern).


ie:

    void push_back(const_reference t)
    {
       PosixScopeMutex psm(mutex);
       Vector.push_back(t);
    };


>> 4. The POSIXCondition class contains *both* the condvar and the mutex as
>> members. Is there any gain from doing this? Moreover, the wait() method
>> takes no parameters. How can I wait for some *condition* (instead of
>> just "signal") to take place?

the pthreads standard only defined one type of conditional break-out
from a condition wait and that is a time-out. which is supported by
the POSIXCondition class. you can pass how many milli-seconds you are
prepared to wait for a signal to come through. If the signal doesn't
come through in the time you pass to the wait method you are returned
saying that you were woken up because you timed-out and not because
you were signaled.

The next level of condition aka boolean variants would be actually a
composite of threads and condition variables. The threads would be
doing the evaluation of the condition themselves i.e.: via a functor or
delegate methodology being fired, on a true result they fire signal or
broadcast.

Signals and slots are how such conditionals are implemented.

the use of the mutex relates to multiple threads having access to the
condition variable. i.e.: multiple threads wanting to raise a signal or
or multiple threads wanting to wait on a signal etc...

>> 5. Coming back to the POSIXThread base class, it contains the static
>> member which is used as a thread start routine. This may not compile on
>> some platforms, since class members (even if static) cannot be made
>> extern "C".

True to some extent. In any case my answer would be get a half decent
compiler. :)


>> I don't claim that this list is complete. ;)
If you do think of any more, please feel free to tell me about them.
also if you have the time, why not have a look at this library and
some of the examples, they use more advance features of the wrappers.

http://www.partow.net/downloads/producer-consumer-source.zip



In any case on the POSIX synchronous page I finally conclude that the
library should be used for educational and demonstrative purposes, and
that other more advanced libraries such as ACE and BOOST should be the
yard stick for implementation of threading libraries within C++.



Regards



Arash Partow
__________________________________________________
Be one who knows what they don't know,
Instead of being one who knows not what they don't know,
Thinking they know everything about all things.
http://www.partow.net

.