Code review comment for lp:~alan-griffiths/mir/fix-1317370
Revision history for this message
| Alan Griffiths (alan-griffiths) wrote | # |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
> This doesn't change the situation on my desktop (which is good to begin with,
> runtime < 1s),
I'm not sure why Daniel and I see this and others do not. (And I can get good timings too if I prevent the test using multiple CPUs.)
The bug mechanism is clear though: the "composite" thread releases and re-acquires the lock thousands of times before the waiting "client" thread can acquire it. This is clearly valid, but unfortunate, thread scheduling. The client thread "getting in" as soon as the lock is released by the compositor is also valid. Different kit exhibits different behavior.