On 14/06/2013 12.43, Gaetano Mendola wrote:
I would like to know if Boost community could be interested in adopting a check mechanism that is able to detect if a not supposed thread safe class is used by multiple threads in unsafe way. This tecnique has saved us a lot of headache especially when code refactoring on old code is performed.
Better to explain it, without enter in the detail of the implementation, with some examples:
Example: Queue implementation non thread-safe but still usable if clients are synchronized somehow.
class NonThreadSafeQueue { public: ... void push(int) { DFAKE_SCOPED_LOCK(push_pop_); ... } int pop() { DFAKE_SCOPED_LOCK(push_pop_); ... } ... private: DFAKE_MUTEX(push_pop_); };
Example: Queue implementation not usable even if clients are synchronized, so only one thread in the class life cycle can use the two members push/pop.
In this case the macro DFAKE_SCOPED_LOCK_THREAD_LOCKED pins the specified critical section the first time a thread enters push or pop, from that time on only that thread is allowed to execute push or pop.
class NonThreadSafeQueue { public: ... void push(int) { DFAKE_SCOPED_LOCK_THREAD_LOCKED(push_pop_); ... } int pop() { DFAKE_SCOPED_LOCK_THREAD_LOCKED(push_pop_); ... } ... private: DFAKE_MUTEX(push_pop_); };
Example: Class that has to be contructed/destroyed on same thread, it has a "shareable" method (with external syncronization) and a not shareable method (even with external synchronization).
In this case 3 Critical sections have to be defined
class ExoticClass { public: ExoticClass() { DFAKE_SCOPED_LOCK_THREAD_LOCKED(ctor_dtor_); ... } ~ExoticClass() { DFAKE_SCOPED_LOCK_THREAD_LOCKED(ctor_dtor_); ... }
void Shareable() { DFAKE_SCOPED_LOCK(shareable_section_); ... } void NotShareable() { DFAKE_SCOPED_LOCK_THREAD_LOCKED(ctor_dtor_); ... } ... private: DFAKE_MUTEX(ctor_dtor_) DFAKE_MUTEX(shareable_section_) };
DFAKE_SCOPED_LOCK will "throw an exception" or will call an "abort" in case of check failed.
This tecnique doesn't involve real lock/unlock but uses atomic operations, also the various macros DFAKE_XXXXXXXXX are defined void when NDEBUG is defined.
Any comment is appreciated.
To whom is interested in it, you can find in my blog http://cpp-today.blogspot.it/2008/06/threading-mess.html http://cpp-today.blogspot.it/2008/06/threading-mess-2.html an early implementation of the technique. My current implementation is different than that one in the blog in the sense that the macros have a different name (see my examples above) and it's using not GCC atomic operations but tbb::atomic. I don't know how to proceed (if) with the proposal for boost, for sure I have to modify my current implementation and write it in terms of boost::atomic (it uses tbb::atomic at the moment). I have also "donated" the code to google chromium project long time ago (I'm not even sure if they are still using it or not) and I don't know if that can be an issue for a boost adoption. Regards Gaetano Mendola