3

I have a C++ program that performs some lengthy computation in parallel using OpenMP. Now that program also has to respond to user input and update some graphics. So far I've been starting my computations from the main / GUI thread, carefully balancing the workload so that it is neither to short to mask the OpenMP threading overhead nor to long so the GUI becomes unresponsive.

Clearly I'd like to fix that by running everything concurrently. As far as I can tell, OpenMP 2.5 doesn't provide a good mechanism for doing this. I assume it wasn't intended for this type of problem. I also wouldn't want to dedicate an entire core to the GUI thread, it just needs <10% of one for its work.

I thought maybe separating the computation into a separate pthread which launches the parallel constructs would be a good way of solving this. I coded this up but had OpenMP crash when invoked from the pthread, similar to this bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36242 . Note that I was not trying to launch parallel constructs from more than one thread at a time, OpenMP was only used in one pthread throughout the program.

It seems I can neither use OpenMP to schedule my GUI work concurrently nor use pthreads to have the parallel constructs run concurrently. I was thinking of just handling my GUI work in a separate thread, but that happens to be rather ugly in my case and might actually not work due to various libraries I use.

What's the textbook solution here? I'm sure others have used OpenMP in a program that needs to concurrently deal with a GUI / networking etc., but I haven't been able to find any information using Google or the OpenMP forum.

Thanks!

ASD1
  • 31
  • 2
  • Do you have to use OpenMP? You could just try using pthreads for everything and it would be easy to have a "Display" thread and a "Computation" thread. – Mike Bailey Mar 12 '11 at 00:39
  • 1
    Sure, nobody strictly *has* to use OpenMP, but I'd rather solve this problem and learn something that just abandon OpenMP and replace it with a more verbose manually managed thread pool – ASD1 Mar 12 '11 at 00:45

1 Answers1

0

There is no textbook solution. The textbook application for OpenMP is non-interactive programs that read input files, do heavy computation, and write output files, all using the same thread pool of size ~ #CPUs in your supercomputer. It was not designed for concurrent execution of interactive and computation code and I don't think interop with any threads library is guaranteed by the spec.

Leaving theory aside, you seem to have encountered a bug in the GCC implementation of OpenMP. Please file a bug report with the GCC maintainers and for the time being, either look for a different compiler or run your GUI code in a separate process, communicating with the OpenMP program over some IPC mechanism. (E.g., async I/O over sockets.)

Fred Foo
  • 355,277
  • 75
  • 744
  • 836
  • This is sort of what I expected from OpenMP. But in your example, how would I actually implement the communication with my GUI program? I'd still probably need to have a separate thread for running my IPC mechanism asynchronously, synchronizing with the OpenMP threads to pull out data etc. And this seems to put me in the exact same spot as I'm already in. The bug I linked was closed as 'RESOLVED INVALID', so I don't think it would help much to file the exact same issue again. – ASD1 Mar 12 '11 at 00:59
  • @ASD1: you don't necessarily need threads for async I/O; you could try `poll`/`select` and perhaps signals to monitor/kill/restart the main program, run multiple instances, etc. It just depends on how much interactivity is needed. (As I said, you could try a different compiler. Intel C++ may be an option, though in my experience, its output performs pretty badly on AMD cores.) – Fred Foo Mar 12 '11 at 01:26
  • Yes, I could use a polling or aysnc method for communication, but this huge limitation of OpenMP will make me abandon it certainly for my current program and likely for all future work. I just don't ever want to be in a situation where I have a fully working program and have to rewrite the threading code just because I want to add some GUI / networking / etc. thread. Which is a shame, cause I thought OpenMP was quite neat. – ASD1 Mar 12 '11 at 01:47