Ok, let me qualify my statement: never assume var++ is atomic unless it is an explicit atomic int or protected by a mutex!
In this specific case neither was an option: I would have had to rewrite some
important chunks of a 3rd-party lib that were already tricky to debug. So I
wrote a workaround making sure the affected data structures do not cross
threads.
The nice thing about killing bugs with tanks is that it is so inefficient and
damaging that it is likely to lead to more (paid) work... ;-)
Funnily enough the same is true for fixing things with sticky tape... ;-)
Konrad
On Thursday, Thursday 21 November 2013 at 19:15, Etienne Sandré-Chardonnal
wrote:
> Hey, that's using a tank for killing a bug. Why not std::atomic<int> or
> QAtomicInt ? In heavy cases (such as mine...) that's a huge performance
> issue and code is also lighter.
>
> 2013/11/21 Konrad Rosenbaum <kon...@silmor.de>
>
> > Hint 2: never assume something as innocuous as var++ is an atomic
> > operation unless it is protected by a Mutex! My most recent hard-to-fix
> > on-Windows-only crash was a race between refcnt++ and refcnt-- in a
> > library that I didn't even write myself (libtcl).
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
