|
Boost Users : |
Subject: [Boost-users] [Threads] and OpenMP
From: Stephan Menzel (stephan.menzel_at_[hidden])
Date: 2014-09-30 05:24:40
Hi all,
I would like to ask around about a strategy on how to tacke the following
threading problem:
I am maintaining a boost intensive portable C++ client-server application
and recently have included a highly complex 3rd party algorithm into my
application that does CPU intense stuff. Long running stuff. Often in the
range of days. While at the same time being heavy in OpenMP usage. Now of
course requirements are that the user has to be able to cancel this.
The algorithm runs in a boost threads controlled background thread. Now I
began to place interruption points throughout the 3rd party code but soon
had to realize that a lot of CPU time is being handled in OpenMP threaded
code regions.
So the question is: How can I more or less gracefully shut this down? How
do interruption points work in an omp parallel for loop? Do I have a chance
at all?
My constraints here are a bit forgiving. Given the complexity of the 3rd
party code I have already accepted the notion that this is gonna be a
memleak monster. Luckily, there's no disk or other hardware access so I'm
ready to live with a certain amount of mem not being cleaned up. Yet the
backend thread communicates with the spawning class by calling a mutexed
callback when it's ready so the user knows it's cancelled. This is
protected by a boost mutex as well. And juding from the horrible threading
"clogs" that I observed in my first trials I suppose this is gonna be a
problem as well.
And input is appreciated. And yes, I am aware that this is gonna be an ugly
mess.
Cheers,
Stephan
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net