Re: [boost] Fwd: [signals2][review] little REVIEW

Subject: Re: [boost] Fwd: [signals2][review] little REVIEW
From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2008-11-11 22:01:40

On Tuesday 11 November 2008 11:23, Stjepan Rajko wrote:
> ---------- Forwarded message ----------
> From:  <Jean-Christophe.BENOIST_at_[hidden]>
> - I am surprised to find very little information or rationale about
> multi-threading in documentation. We know the library is now "thread
> safe" but we don't know exactly what it means. There is only one MT
> use case (just) detailed in "tutorial" : what happens when a thread
> disconnect a slot from a signal, while another thread calls it. But
> there are another interesting MT use cases :
>    - what if 2 threads simultaneously calls the same signal ? How to
> mutex slots in this case ? Are slots automatically excluded by an
> hidden mutex ?

Yes, I'll put something about that when I add the thread-safety section to 
the design overview.  The signal does not hold any locks when it runs a 
slot.  Signals only use mutexes to protect their own data (like the list 
of connected slots).  So a signal invoked concurrently by multiple threads 
can result in a slot to running concurrently.

>    - What if a thread adds a slot to a signal while another calls it ?
> Is the slot added after signal call ?

Once a signal invocation starts running slots, it won't see any new slots 
connected until the next time it is invoked.  It will see disconnections 
of slots it hasn't reached yet though.

> - About rationale : why is there special signals2::mutex ? May we use
> boost::thread::mutex for mutex template ? 

Yes.  There is a sentence in the signals2::mutex description that suggests 
using boost::mutex if you are using Boost.Threads.  

> What are 
> advantages/drawbacks of choosing signals2::mutex or
> boost::thread::mutex ?

signals2::mutex is just a header-only mutex.

> - Use of "postconstructible" or "predestructible" classes is rather
> obscure, and should be tutorialized / better documented.

Yes.

> * On test suite / test cases :
>
> - I cannot see any MT test case (from the documentation, in
> "acceptance tests" section at least). It's rather surprising. I cannot
> imagine there is no test case for MT (calling a signal while
> disconnecting slot etc..). In particular, I'd whish to see if this
> library is robust in a multi-core environment and run test cases in
> this environment (I know cases where a library is perfectly thread
> safe on mono-core, even hyperthreading, but fails on multi-core). At
> least, there should be a rationale explaining why this library should
> be robust in a multi-core environment (especially with a proprietary
> signals2::mutex).

It's not obvious to me how to write a test for the library's 
thread-safeness that is any more focused than "we did some signals stuff 
in multiple threads and the program didn't crash".  It's sort of like 
writing a test for memory leaks.  What you need is a debugging tool, like 
what valgrind's helgrind tries to be.  Then you can have your 
multi-threaded test program, and the test is whether or not the debugging 
tool detected any funny business (like multiple threads messing with the 
same variable without locking).