[Interest] Using valgrind to detect threading errors in qt5 code

[Thiago Macieira]

On terça-feira, 10 de abril de 2012 22.46.38, Paul Floyd wrote:
> On 10 Apr 2012, at 22:28, Thiago Macieira wrote:
> > On terça-feira, 10 de abril de 2012 21.44.49, Paul Floyd wrote:
> >>> As for Qt 5, since locking and unlocking is inlined into the user code,
> >>> valgrind might be completely unable to work.
> >> 
> >> If the code is inline, then all I can think of would be to recognise the
> >> opcode sequence and proceed from there.
> > 
> > It's very hard to distinguish a "lock cmpxchg" sequence doing locking from
> > the same code sequence doing something else, like allocating a timer ID
> > in the lock-free QFreeList.
> 
> I imagine that there is more than just that one opcode to the lock.

Not a lot of them. But either way, both operations are implemented using the 
same function:

template<int size> template <typename T> inline
bool QBasicAtomicOps<size>::testAndSetRelaxed(T &_q_value, T expectedValue, T 
newValue)
{
    unsigned char ret;
    asm volatile("lock\n"
                 "cmpxchg %3,%2\n"
                 "sete %1\n"
                 : "=a" (newValue), "=qm" (ret), "+m" (_q_value)
                 : "r" (newValue), "0" (expectedValue)
                 : "memory");
    return ret != 0;
}

Those are the exact same two instructions (lock is a prefix, not an 
instruction) in both cases. The loading of the inputs and the reading of the 
outputs can be located very far away from these two.

> If there isn't an unique signature, then one could be made using the
> technique used by the Valgrind client request macros: a signature sequence
> of opcodes [4 'rol edi's that sum to 64 bits of rotation, leaving edi
> unchanged] that would 'never' be emitted by a compiler is inserted inline. 
> The downside is that this would require either a special build of Qt or a
> small overhead if always built in (and I expect that the lock/unlock code
> is rather performance critical).

I need to look into that.

In any case, I've been thinking of de-inlining this code for other reasons, 
mostly to do with performance. I want to implement the transactional memory 
extensions of Intel's next, next processor.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20120410/d5857b5e/attachment.sig>