[Development] QMutex with pthread on Linux

[marius.storm-olsen at nokia.com]

On 8/22/12 7:58 PM, "ext Thiago Macieira" <thiago.macieira at intel.com>
wrote:
>With adaptive locking:
>RESULT : tst_QMutex::contendedQMutex():"no msleep, 2 mutexes":
>     1,961,622.638 CPU ticks per iteration
>       5561.854224 task-clock                #    3.781 CPUs utilized
>     
>    17,706,600,180 cycles                    #    3.184 GHz
>     
>    13,209,273,979 instructions              #    0.75  insns per cycle
>     
>         8,072,609 raw_syscalls:sys_enter    #    1.451 M/sec
>     
>       1.471046980 seconds time elapsed
>
>Adaptive locking is a busy-wait spin ahead of the sleep, iterating 1000
>times 
>trying to acquire the mutex. The Qt 4 solution was time based, whereas
>the one 
>I'm implementing is a fixed number of cycles. It's similar to Glibc's
>solution, 
>which is also a number of cycles.
>
>Note that the "without adaptive locking" solution still tries to acquire
>it 
>once again. Without that, the results are much, much worse. I decided
>that 
>trying once was an acceptable comparison because Olivier's original does
>try 
>to lock once before trying to sleep.
>
>In *this* particular case, it runs in less time and with less CPU time,
>but in 
>other cases it's not the same. In the msleep(2) case, it runs in similar
>time 
>as pthread, but it uses roughly 33% more CPU.
>
>Conclusion: the biggest gain is the adaptive locking, even though it
>introduces a busy-wait. I'd recommend keeping it and making it smarter,
>really 
>*adapting* to how often the mutex is contended.

If we should "keep it", we first need to see it :) I couldn't find it in
your changes list?

-- 
.marius