The critical section has a significant wait time indicated by the long bar. If we expand this we see pthread_mutex_lock->draw_task::operator(). Right clicking on draw_task underneath pthread_mutex takes us to the source code line, showing the draw_task function had to wait before it could draw and during this wait time the critical section is repeatedly contested. We discuss why the section of code is thread safe and remove the Lock.
- [Instructor] We can go straight to the line of code…where draw task is being called by right clicking on it…and selecting View Source.…We can see the source code if we click on the edge…and drag this to the right to get a clearer view.…We can see the call where RGB mutex is acquired…in order to safely perform some pixel calculations.…The draw task function was waiting 357 seconds…while this code line was executing,…and during this time the critical section was contended.…If we scroll to the right,…we can see the column with the wait count,…which shows this was contended 509 times.…
Vtune has shown us where the application is serializing.…Each thread must wait for 357 seconds…in order for the mutex to be available…before it can proceed with the render one pixel call.…We need to fix this in order to have better parallelism.…If we right click on the pthread mutex lock line…and select Edit Source,…we will be taken right to that line inside Visual Studio.…The RGB mutex looks like it was introduced…with the intention of protecting pixel calculations…
By the end of this course you will know how to use the Locks and Waits analysis on your own application and improve the efficiency of parallel task execution on Windows.
- Installing VTune Amplifier
- Choosing options for the Locks and Waits analysis
- Working with the VTune Amplifier GUI
- Viewing the analysis summary
- Removing the lock
- Conducting lock-removed analysis
- Comparing results