Hey,
For the sake of completeness of this thread:
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.
Best regards,
Karli
