PureBasic Forums - English

I have encountered an issue -- with rapid lock/unlock in multiple threads, the program eventually hangs waiting for a lock.
Absolutely, any lockmutex is countered by unlock.. w/o a dobut.
Is there a way to timeout the mutex?

Absolutely, any lockmutex is countered by unlock.. w/o a dobut.

No, if that was the case, they mutex wouldn't hang. The whole point of the mutexes is that they work correctly with rapid lock/unlock from multiple threads. The bug must be in your program.

Right -- ok; bug in my program; but that doesn't answer the question...


UPDATE: I made 1 change - I said "use the standalone debugger" -- recompiled, program works as expected (no hangs).
Reset the compiler to "built in" -- and the hang happens again.

Have you verified correct operation with no debug code? The usual way is to put a counter in each thread, activate the thread a large number of times and see if counters between caller and "callee" drift apart.

buddymatkona wrote:Have you verified correct operation with no debug code? The usual way is to put a counter in each thread, activate the thread a large number of times and see if counters between caller and "callee" drift apart.

I have verified that for every Lock there is an unlock.
I have verified this at least 3 different ways.

In that case, you may have run into the same problem I did.
http://www.purebasic.fr/english/viewtop ... 13&t=44565

If you run code from http://www.purebasic.fr/english/viewtop ... 13&t=44565
in several parallel threads, you will see the default PB Debugger using bad addresses. ( A dual processor might not be enough to reproduce this problem.) You will need to make a small change to get the code to run in parallel with debug code added.
In "Macro ThreadLoop" :
"CompilerIf #PB_Compiler_Debugger = 0" should be changed to "CompilerIf #PB_Compiler_Debugger <> 0"
Then compile with Debugger.

Thanks.

Cheers
-j

Does the program run ok without the debugger?

Trond wrote:Does the program run ok without the debugger?

I don't recall right now - as I was focused on debugging the issue -- but I tend to think it wasn't.

Did you enable 'Threadsafe' compiler option?
And there is command called TryLockMutex() which you can call in loop and every time it fails then add small Delay(), at end of loop calculate total time wasted in loop and Break if desired time has passed (= timeouted).

@cas, I also over looked TryLockMutex() while I was wondering if there was a way to go ahead and do other stuff until the mutex was unlocked. Good tip.

I don't think a program should 'hang' at LockMutex() because (if I understand correctly) that request would get in line and wait it's turn, instead of constantly trying over and over until successful. I have noticed, before learning how to use mutexes, a program that I wrote with threads (accessing the same global variables) and without mutexes, seemingly wouldn't crash at all or would run longer with the debugger on. With the debugger off or compiled, it crashed almost instantly. Don't know why that is. But My guess is that somewhere in your program, there is a line that's trying to access to a global or shared variable (that is used in the threads) and isn't checking the mutex.

As far as debugging output, the code for the CreateMutex() example uses a Console to display the count instead of using the debug window. Maybe they know something we don't?