Debugging Critical Section lockups

[Robert Shearman]

David D. Hagood wrote:

> Robert Shearman wrote:
>
>> David D. Hagood wrote:
>>
>
>>
>> Unless the installer is using TryEnterCriticalSection, I would expect 
>> CPU utilisation to be 0% when deadlocking.
>
>
> Yes, *once the deadlock occurs* the CPU drops to 0%. The issue (I 
> think)  is more along the lines of this:
>
> On fast CPU:
>
> thread 1 locks resource A, does something, locks B, unlocks B, unlocks A.
>
> Thread 2 locks B, does something, locks A, does something, unlocks  C, A.
>
> On slow machine:
>
> Thread 1 locks resource A, does something.
>
> Context switch.
>
> Thread 2 locks B, does something.
>
> Context switch
>
> Thread 1 tries to lock B and blocks.
>
> Context switch.
>
> Thread 2 tries to lock A and blocks.
>
> Deadlock.
>
> In other words, on the fast CPU the deadlock does not happen because 
> thread 1 gets everything done before thread 2 starts. On the slow 
> machine, thread 2 starts while thread 1 is still doing stuff.


Yep, example of what not to do in concurrent programming. You should 
make a note of the order in which locks are taken and always take the 
locks in that order and always release them in the opposite order.

You have several options from here:
1. File a bug report with the maker of the application.
2. Find a function that B uses just before it locks that A doesn't use 
and add a Sleep call. Obviously this kind of fix won't be accepted into 
Wine.
3. Do tests to try to find a function that A uses that is much slower on 
Wine and try to fix it.

-- 
Rob Shearman