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

Subject: Re: [boost] Proposal for a thread "collision" detector
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2013-06-16 10:32:09

I'd be interested.

Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Gaetano
> Mendola
> Sent: Friday, June 14, 2013 5:44 AM
> To: boost_at_[hidden]
> Subject: [boost] Proposal for a thread "collision" detector
> 
> 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.
> 
> 
> Regards
> Gaetano Mendola
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost