Re: [boost] Proposal for a thread "collision" detector

Subject: Re: [boost] Proposal for a thread "collision" detector
From: Gaetano Mendola (mendola_at_[hidden])
Date: 2013-06-24 16:33:34

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