Boost logo

Boost :

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

  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);

  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

 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.



Boost list run by bdawes at, gregod at, cpdaniel at, john at