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.