Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk