[boost] Fw: Some Boost.Threads observations

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-06-21 08:28:30

I sent this once already, but it doesn't appear to have been received, so
I'm resending.

----- Original Message -----
From: "William E. Kempf" <wekempf.nospam.for.you_at_[hidden]>
> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
> news:009001c21852$f728db30$1d00a8c0_at_pdimov2...
> > 1.
> >
> > explicit thread::thread(const boost::function0<void>& threadfunc);
> >
> > Shouldn't this be
> >
> > template<class F> explicit thread::thread(F threadfunc);
> >
> > As it is, implementors are forced to roll their own function0<void>.
(How
> > does CoreX deal with this?)
>
> Yes.  That's something I noticed while working on the next revision and
I'm
> planning to fix it.  Thanks.
>
> > 2.
> >
> > Has it been pointed out that the current mutex/scoped_lock model is
> > equivalent in expressive power to a mutex with public lock/unlock
methods?
> >
> > class my_mutex
> > {
> >     mutex m;
> >     mutex::scoped_lock l;
> >
> > public:
> >
> >     my_mutex(): l(m, false) {}
> >
> >     void lock() { l.lock(); }
> >     void unlock() { l.unlock(); }
> > };
>
> This isn't really true.  The above class can't be shared between threads
> safely, because ScopedLocks aren't thread safe.  They maintain state that
> indicates whether or not the lock is held, and this state isn't (can't be)
> synchronized.
>
> > 3. Speaking of template<class F>, are there plans to extend boost::once
to
> > accept function objects?
> >
> > template<class F> void once(F f, once_flag & flag);
>
> Yes.  I also plan to allow thread_specific_ptr<> to be registered with
> specific cleanup handlers, which will also be function objects instead of
> functions.
>
> > Minor documentation details (once.html): 'implementation defined' should
> be
> > 'unspecified'; the Effects/Posconditions imply that once_flag is
equality
> > comparable, is this intentional?
>
> I'll switch to unspecified.  No, it wasn't intentional to imply that
> once_flag is equality comparable.  The check is something that only the
> implementation should be allowed to do.  I'll work on the description here
> as well.  Thanks for this.
>
> > 4. Are there plans to supply a statically initialized mutex, to avoid
init
> > order problems?
> >
> > (BTW, 3 can be implemented given 4, and vice versa, but neither can be
> > implemented efficiently on top of the current architecture AFAICS.)
>
> This one is just wrought full of issues.  I'm still considering it and the
> impact involved.  It is one of the key things missing in Boost.Threads
right
> now, but as you point out (if I understand your "BTW" comments) all that's
> compromised is the possibility for some optimizations.  You can still
> achieve the desired effect by initializing a dynamic mutex via a once
> routine.
>
> > 5. Are there plans to integrate detail::lightweight_mutex with
> > boost.threads?
>
> You mean the stuff from shared_ptr?  I'm paying close attention to this
(and
> the ref-counting stuff, which belongs in this library as well), but there
> are issues with portability/memory visibility.  Eventually I'll probably
> apply these optimizations, but I want to see how well they are received by
> shared_ptr users first.
>
> Bill Kempf
>
>