OpenMP® Forum

Discussion on the OpenMP specification run by the OpenMP ARB. OpenMP and the OpenMP logo are registered trademarks of the OpenMP Architecture Review Board in the United States and other countries. All rights reserved.

I've been considering writing some of my first multiprocessing code and I'm lookiing at using OpenMP. Having browsed some parts of the spec it seems that OpenMP doesn't have much to say about communicating between runningthreads, although it does have facilities for handing data to a new thread and getting data out of a thread that has completed its run.

My application has a highly parallelisable subproblem which requires somecommunication between the threads and a master while running each instanceof the subproblem. Perhaps more importantly, this subproblem may need to be solved many many times during an execution of the program. It seems wasteful to have to set up and tear down the many threads needed for the subproblem. I'd rather set them up once and then hand them a batch of work to complete, then leave them waiting on a mutex or something until there's another batch of work to do.

C++11 has things called promises and futures which are intended to be used mainlyfor inter-thread communications. Promises and futures may be suitable for gettingdata between threads in my application.

Does anybody know whether C++11 promises and futures play nice with OpenMP?

FWIW, I'd most likely be using GCC 4.7, so OpenMP 3.1 features would be available.

I would not recommend trying to mix OpenMP with C++11 threading features. There is nothing to specify how the two APIs are supposed to interact, and even if it did "work" with GCC, you would most likely have non-portable code. You should be able design a C++11 program to create threads once and keep them alive.

> I'm curious, would you describe what you need to do? perhaps at a pseudo code level...?

I don't want to go into detail, but here's an outline:

1 Do some inherently sequential processing to decompose the problem into a (possibly large) number of (possibly large) data structures which must later be manipulated in synchrony.

2 Solve a (large) number of subproblems on variants of the aforementioned data structures, In each of a number of threads: a) while communicating with a master thread regarding modifications to the data structure, b) while modifying a copy of the data structure in response to those instructions, c) while detecting specific changes in the data structure and reporting them to the master, d) when the master indicates that there are no more modifications necessary, return a copy of the final version of the data structure to be stored for later use, e) wait for another unit of work or for an instruction to terminate the thread.

3 Examine the final products to find solutions to the original problem.

Sorry to be so vague, but I don't really want to get into the specifics of the problem at handat this point and in this forum I'm only interested in discussing the concurrency-related aspects.

BTW, I've recently noticed that the GCC online docs mention that C++11 futures are partially implemented in at least the latest svn repository.