[petsc-dev] Possible bugs when using TS with ViennaCL

[Karl Rupp]

Hey,

>>> Mani's build included
>>> --with-threadcomm --with-pthreadclasses --with-openmp
>>> which seems the be the cause of the problem. Without these flags,  the
>>> problem disappears and results are correct. If I remember correctly,
>>> this is a more fundamental problem in threadcomm rather than specific to
>>> the ViennaCL bindings, yet we clearly need to fix it.
>>
>> [repost from petsc-maint]
>>
>> Evidently threads are a liability right now.  Do you know what caused
>> this behavior so we can avoid it in the future?
>
> Unfortunately I don't know what exactly is causing the problem. My best
> guess is that one of the sys-calls inside threadcomm is in conflict with
> the internals of the OpenCL runtime. I'll see whether I can reproduce
> this on my machine, then I can incrementally disable parts of threadcomm
> until I found the cause.

Okay, I could reproduce this problem on my machine: A configuration 
including
  --with-threadcomm --with-pthreadclasses --with-openmp
fails, while
  --with-threadcomm --with-pthreadclasses
works. Note that all runs are single-threaded, so it is only the 
presence of -fopenmp which screws things up. The most immediate 'fix' is 
to prevent the combination of OpenMP and OpenCL at the configure stage. 
The problem does not show up in a fresh build with CUDA and CUSP, at 
least not when using the standard ComputeResidual() based on VecGetArray().

Best regards,
Karli