Deadlock with JTP in executeJava

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a simple kernel like "data[getGlobalId()]=0"
2. Execute it with mode=JTP and an array of 5 elements

What is the expected output? What do you see instead?
Expected kernel to complete, but instead it hangs forever.

What version of the product are you using? On what operating system?
2011-10-13, or r89 on Win7 x64, but 32bit Java

Please provide any additional information below.
It looks as if the barrier is placed inside the loop that generates the 
threads. If numThreadSets is more than 1, it will need to do an extra loop with 
thrSetId (line 690), but the synchronization happens inside the loop, so it 
will block waiting for the threads to finish, but they are not created, hence a 
deadlock.

I have attached a patch where I have moved the synchronization outside the 
loop, and that seems to work for me. It should not do bad things because it is 
apparently just waiting for all threads to complete before starting the next 
pass.

Original issue reported on code.google.com by kenneth@hexad.dk on 18 Oct 2011 at 1:53

Attachments:

• [Aparapi JTP Locking issue.diff](https://storage.googleapis.com/google-code-attachments/aparapi/issue-7/comment-0/Aparapi JTP Locking issue.diff)

[GoogleCodeExporter]

Ken do you have a small sample that we can use to validate this.

I worry that your patch will break code expecting each synthetic group (we 
create for jtp mode) to behave like opencl. It might not :-) but i woul like to 
look at it more.

A small test sample would help me try to work out why the deadlock occured.

Oh can you tell me how many cores your cpu has, and what was the value you used 
for kernel.execute().

Thanks for reporting this. And for the proposed patch.

Original comment by frost.g...@gmail.com on 18 Oct 2011 at 2:23

• Changed state: Accepted

[GoogleCodeExporter]

I have 2 cores which is why it makes two threads.
This deadlocks on my machine because numThreads == 2:

 Kernel k = new Kernel() { @Override public void run() { } };
 k.setExecutionMode(EXECUTION_MODE.JTP);
 k.execute(5);

Original comment by kenneth@hexad.dk on 18 Oct 2011 at 2:50

[GoogleCodeExporter]

yeah this looks like a bug. This should force a single thread to be created to 
match OpenCL's strategy, but it looks like it is using two threads.  Which is 
wrong because 5 is prime we should have launched a single thread.

So when we use kernel.execute(n) in either mode we need to break the global 
size into equal groups (for GPU, CPU or JTP mode). Because 5 is prime the only 
equal group size we can choose is 1. 

In general this is why our examples (and most OpenCL examples) choose to use 
powers of two for global size. Of course this is not always possible, sometimes 
your required globalsize is not a power of two, because your domain size is not 
a power of two.

Try this for a workaround. In your Kernel write something like

public void run(){
   if (getGlobalId()<6){
      // put your current code here
   }
}  

Then use kernel.execute(8) just to see if this works. 

In the meantime I will try to work out why we are not constraining the 
execution to a single thread in this case. 

Original comment by frost.g...@gmail.com on 18 Oct 2011 at 3:01

[GoogleCodeExporter]

Yes, it works with kernelsize=8, this will create 4 threads.

What you are saying makes sense. You should not use my patch, because the 
deadlock happens because of wrong size parameters. I'll let you figure out how 
to calculate the right parameters :)

Original comment by kenneth@hexad.dk on 18 Oct 2011 at 3:22

[GoogleCodeExporter]

Ken

I think this should now be fixed as part of my recent branch merge #r258.  Can 
you confirm?

Original comment by frost.g...@gmail.com on 14 Feb 2012 at 5:43

[GoogleCodeExporter]

Original comment by frost.g...@gmail.com on 14 Feb 2012 at 5:43

• Changed state: Verified

[GoogleCodeExporter]

Original comment by frost.g...@gmail.com on 14 Feb 2012 at 5:46

• Changed state: Fixed

[GoogleCodeExporter]

Sorry, I do not have the machine that caused the problem anymore :(

Original comment by kenneth@hexad.dk on 3 Mar 2012 at 7:12