Re: [boost] [threads] Future directions (Was: TR2 and C++0x heads up)

From: Ion Gaztañaga (ion_g_m_at_[hidden])
Date: 2005-04-24 07:11:19

>> Is this something that's already being worked on? I have some ideas
>> that I've been thinking about to improve Boost.Threads, and some
>> other ideas that have  been suggested to me (primarily by Roland
>> Schwarz), that I'd like to at least get other people's opinions of before
>> a Boost.Threads proposal goes too far. Some of the ideas come from
>> the big lock-unification discussion that took place on this list some 
>> time
>> ago (although I think I've come up with some interesting ideas on that
>> topic that weren't mentioned in that discussion). I have some other
>> ideas as well that I think people might find intereting.
>
> I'm interesting in reworking some areas of Boost.Threads that I find 
> lacking, so you should probably announce your plans so that we can avoid 
> duplication of efforts.

Sorry if this is not the place to discuss it, but if we have some discussion 
about threads, I always wondered why thread () constructor launches 
automatically a thread in constructor. This means that when you code an 
active class (I mean, I class that represent a task in other thread), if you 
want to start it on demand, you must use dynamic memory constructing the 
object in heap.  I mainly work in embedded systems that may not have dynamic 
memory and I think an static way should be provided, since those systems do 
have threads. I would prefer an option like this:

class work_in_other_thread
{
  work_in_other_thread(const boost::function0<void>& func)
   : m_thread(func){}

  void start_work()
    { //this function does not exist in boost threads
       m_thread.start();
    }

 private:
  boost::thread m_thread;
};

instead of :

class work_in_other_thread
{
  work_in_other_thread(const boost::function0<void>& func)
   : mp_thread(0), m_func(func) {}

  void start_work()
    {
       m_thread = new boost::thread(m_func);
    }

 private:
  std::auto_ptr<boost::thread> mp_thread;
  boost::function0<void> m_func;
};

  I see also dynamic memory in proxy functions in the code, but I think it's 
an implementation detail that could be optimized in systems when needed, 
storing needed data  in boost::thread class if it is a joinable thread. Or 
we could use an internal, hand-made segregated storage pool for data needed 
by boost::threads.

 I don't want to start a flame war, but I would suggest a dual start 
now/start on demand approach, adding a different constructor and a trigger 
function.

 I also think that the standarization of the lock interface is important. 
Currently, I'm working in shmem library mimicking boost locks/conditions for 
process-shared locks/conditions. Boost threads explicitly checks for 
multithreaded build when including thread locks (for example scoped_lock) 
and it would be nice to reuse those locks in single threaded processes using 
process-shared mutexes. Ditto for xtime structure.

 Sorry for the lenghty post about threads, it is just that I couldn't resist 
it! I would be glad to discuss some boost thread aspects if there is a 
opportunity for this.

Regards,

Ion