Any particular reason why this should lock-up?

Everything else that doesn't fall into one of the other PB categories.
srod
PureBasic Expert
PureBasic Expert
Posts: 10589
Joined: Wed Oct 29, 2003 4:35 pm
Location: Beyond the pale...

Any particular reason why this should lock-up?

Post by srod »

The following occasionally freezes before displaying the window under PB 5.62x64, Win 7, but only if the debugger is enabled, and, it would seem, the PauseThread() is not commented out!

The threadsafe switch doesn't seem to matter in terms of preventing the freeze, nor does it matter which debugger I use.

Just wondering if anyone can confirm that I am not going nuts! It took an age for me to track down an occasional lock up in a far bigger program than this, but have whittled it down to this small snippet and am just a little puzzled especially as the problem disappears if I disable the debugger or comment out the PauseThread() (only 90% sure about this)!

Could the PauseThread() be also pausing the debugger (which makes sense) which in turn is pausing the main process somehow? If so, why does this problem only occur intermittently?

Code: Select all

;The occasionally freezes on my system : PB 5.62x64, Win 7.
;Comment out the PauseThread() or disable the debugger to remove the problem (apparently!)

Procedure thread(param)
  Repeat
    Delay(100)
  ForEver
EndProcedure

threadID = CreateThread(@thread(), 0)
PauseThread(threadID)

If OpenWindow(0, 0, 0, 222, 200, "ButtonGadgets", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
  ButtonGadget(0, 10, 10, 200, 20, "Standard Button")
  Repeat
    ev = WaitWindowEvent()
  Until ev = #PB_Event_CloseWindow
EndIf
I can get around this easily enough in that I will switch a reliance on PauseThread() for the use of a semaphore object in my case.

Thanks.
I may look like a mule, but I'm not a complete ass.
User avatar
skywalk
Addict
Addict
Posts: 3972
Joined: Wed Dec 23, 2009 10:14 pm
Location: Boston, MA

Re: Any particular reason why this should lock-up?

Post by skywalk »

Yes, I noticed strange effects with PauseThread() in a debugged threaded app. It was not always immediate pause. Using Semaphore's was much more stable while debugging my threaded app. Once the Semaphore's were working, there was no reason to go back and check PauseThread() for the final exe.
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
srod
PureBasic Expert
PureBasic Expert
Posts: 10589
Joined: Wed Oct 29, 2003 4:35 pm
Location: Beyond the pale...

Re: Any particular reason why this should lock-up?

Post by srod »

Ah maybe I am not entirely nuts after all! :) Cost me a couple of hours work mind locating the reason for the intermittent problem!

Yes, a semaphore object always made more sense anyhow right from the beginning. I was only using PauseThread() because I was too lazy to do otherwise! :)

Thanks.
I may look like a mule, but I'm not a complete ass.
freak
PureBasic Team
PureBasic Team
Posts: 5929
Joined: Fri Apr 25, 2003 5:21 pm
Location: Germany

Re: Any particular reason why this should lock-up?

Post by freak »

PauseThread() is a rather dangerous command since you don't know where you interrupt the thread. If the thread is currently holding any kind of synchronization lock you can easily cause a deadlock. So it should be avoided wherever possible. (in retrospect, it was probably a bad idea to even add it to the library, just like KillThread())

The debugger itself also does some synchronization when PB code is executed this is why you hit a deadlock here, but it could happen in basically any library command as well.

Telling the thread to stop/wait via semaphore or other synchronization object is the only safe way (debugger or no debugger), since the thread will stop in a clearly defined place.
quidquid Latine dictum sit altum videtur
srod
PureBasic Expert
PureBasic Expert
Posts: 10589
Joined: Wed Oct 29, 2003 4:35 pm
Location: Beyond the pale...

Re: Any particular reason why this should lock-up?

Post by srod »

The thread in question (in my large app) could only ever be 'polling' for my apps thread-messages when a PauseThread() could be issued (as opposed to actually processing one of these messages) which is why I figured it would be okay.

Lesson learned! :D

The semaphore is working absolutely fine in its place. That would have saved me a few hours had I not tried to cut corners in the first place!

Thanks Freak.
I may look like a mule, but I'm not a complete ass.
Post Reply