On Tuesday 11 November 2008 11:23, Stjepan Rajko wrote:
---------- Forwarded message ---------- From: <Jean-Christophe.BENOIST@fr.thalesgroup.com> - 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).