Wrong said fred

General JUCE discussion
1

morning. (or whatever)

I’ve got a Thread class which is basically

run() { while ( ! threadShouldExit ) { data = readFromBufferThatInvolvesCritSecs(); process->process( data ); } }

the GUI has a “stop” button which calls stopThread(-1) on this thread

“process” communicates with the GUI by sending “listener” type messages which get displayed after using a MessageManagerLock.

sometimes it won’t stop! hourglass spins away forever. and as per-fooking-usual this refuses to happen in anything but a release build.

I put some trace logging about the place and it is just hanging on stopThread(-1) (I don’t really want the thread getting forcibly killed)

anyone see anything I’m doing wrong?

thanks

chris

PS I can’t go on holiday until I’ve fixed this!

2

Sounds like a deadlock - your thread that’s calling stopThread will already have the message manager locked, but maybe the other thread is at the same time waiting to lock the messagemanager so it can send its listener callback?

3

yep. I think thats the story!

I think I’ve sorted it by putting a guard on the callbacks so that they (and the MML they use) get bypassed while the system is stopping.

I tested and it stopped and restarted cleanly over 30 times.

It was a hunch and your reply seems to confirm this.

thanks jules!

c

4

You can use this deadlock detector to locate exactly where your deadlock occurs…

(Simply build in release with the generate .MAP file option)

5

thanks X.

I’ll try that on the unfixed version to confirm.

c

6

[quote=“X-Ryl669”]You can use this deadlock detector to locate exactly where your deadlock occurs…

(Simply build in release with the generate .MAP file option)[/quote]

how on earth does this thing work? does not seem to do anything!

load map then process? ??

anyway…

how should I go about stopping a thread that uses MMLs? At the moment I’ve got a boolean guard condition around the attempt to take MML and I’ve added a Thread::sleep( 100 ) before the stopThread(-1) to allow any immediatly pending MML requirements to complete.

pseudocode for stopping…

set acceptevents = false sleep 100 stopthread ( threadWotSendsTheEvents )

for event callback

procedure onEvent
start
  if acceptevents
    start
       get MML
       doGUIStuff
    end
end

good? bad? terrible? dodgy archetecture to begin with?

c

7

For the deadlock detector,
[list]
[]Click on the open icon (and select your EXE)[/]
[]The process load and inject the dll inside (you should have a message box)[/]
[]Do like you would in real life until the deadlock happens[/]
[]When you’ve passed the usually deadlocking state, click on “File/Load map file”[/]
[] Select the map file that is link with your exe[/]
[] Click analysis menu/ Full analysis[/]
[] The list update as long as the analysis goes. The deadlock are shown in orange (warning-understand might deadlock in release mode) or dark-red(real deadlock).
If the map file is correct, you’ll have the last function name on the last column.[/][/list]

Adding sleep is never a good idea (it masks the problem but doesn’t solves it).

8

[quote=“X-Ryl669”]For the deadlock detector,
[list]
[]Click on the open icon (and select your EXE)[/]
[*]The process load and inject the dll inside (you should have a message box)
[/quote]

crashed here in >ThreadSpy.dll!1000421b()

[quote][/]
[]Do like you would in real life until the deadlock happens[/]
[]When you’ve passed the usually deadlocking state, click on “File/Load map file”[/]
[] Select the map file that is link with your exe[/]
[] Click analysis menu/ Full analysis[/]
[] The list update as long as the analysis goes. The deadlock are shown in orange (warning-understand might deadlock in release mode) or dark-red(real deadlock).
If the map file is correct, you’ll have the last function name on the last column.[/*][/list]

Adding sleep is never a good idea (it masks the problem but doesn’t solves it).[/quote]

what are alternatives? more locks? the sleep is just to allow anything currently inside the event callback to finish.

9

I’ve sent to your email address the last version of the deadlock detector.
Try to use the compiled version, and if doesn’t work compile it yourself in release mode.

Concerning your “solution”, the problem will happen if the other threads take longer to finish than your “wait” time. This usually happens when the computer is very, very busy, CPU is full etc…

So you’ll probably say let’s wait longer. Doing so will simply decrease the reactiveness of your software while still suffering from the previous bug.

The only solution I’ve found to prevent deadlock so far is to draw the thread object locking order (you’ll have to take a very long piece of paper).
Something like thread A locks object 1 then object 2 then object 3, release object 2 then object 3 then 1 then locks object 2 release it, etc…
At the same time thread B locks object 1 then object 3 then object 2, release 2 then 3
If two threads cross their object locking order (like in the previous example it is going to deadlock on object 3 and 2) they will deadlock.

To prevent this, always lock the objects in the same order in all threads.
BTW, the deadlock detector simply does this checking for you.

10

[quote=“X-Ryl669”]I’ve sent to your email address the last version of the deadlock detector.
Try to use the compiled version, and if doesn’t work compile it yourself in release mode.

Concerning your “solution”, the problem will happen if the other threads take longer to finish than your “wait” time. This usually happens when the computer is very, very busy, CPU is full etc…

So you’ll probably say let’s wait longer. Doing so will simply decrease the reactiveness of your software while still suffering from the previous bug.

The only solution I’ve found to prevent deadlock so far is to draw the thread object locking order (you’ll have to take a very long piece of paper).
Something like thread A locks object 1 then object 2 then object 3, release object 2 then object 3 then 1 then locks object 2 release it, etc…
At the same time thread B locks object 1 then object 3 then object 2, release 2 then 3
If two threads cross their object locking order (like in the previous example it is going to deadlock on object 3 and 2) they will deadlock.

To prevent this, always lock the objects in the same order in all threads.
BTW, the deadlock detector simply does this checking for you.[/quote]

ta.

I have replaced the sleep with a WaitableEvent

11

sleeping for a bit was a bit crap eh?

what was I thinking?