Workaround for using printf within openmp parallel regions in mex files?

Hello!

I wrote parallel c code with openmp. In several places, the code checks for errors and in case they are found it prints out a message (printf()), and exits (exit()).

Then I made a mex function from this code.

One problem to consider is that its forbidden to use printf because the header file mex.h redefines it as mexPrintf which is not thread safe. Thus all the error messages can not be printed, and the program just exits without giving a clue about the nature and location of the error.

Consider the following suggestion for a workaround: Put the call to printf in a function my_printf() which sits in a seperate file that does not include the mex.h file. This function can look somthing like

void my_printf(char * error_message){

   printf("%s \n", error_message);
}

Since this function is in a file which does not include mex.h the printf is not redefined to mexPrintf and behaves just like a "normal" c printf, i.e. thread safe.

Other workarounds can be to use output functions which are not redefined to mex API functions in mex.h. For example, printing error messages to a file using fprintf, or printing to screen with puts().

Does anyone have experience with this? Might it work?

[Ilan]

To avoid problems the function should probably avoid interacting with matlab in any way. Printouts should be directed away from the matlab command window (e.g. to a terminal screen or a file).

Answer 1

[Jan]

You can use a semaphore to block concurrent calls of mexPrintf. One idea is to create an dedicated thread for writing messages, which blocks further calls, until the message is written.

Because this is not a Matlab related problem, I suggest to ask Google for "multithread debug" or similar keywords.

[Ilan]

Jan, Thanks for your reply.

I am not sure I would say it is not a matlab problem. In c printf is perfectly thread safe. The problem comes from its redefinition in mex.h.

The solution you suggest is feasible, another possibility would be to use some kind of error flags, perform problematic sections conditionally depending on the vaules of these flags, and then printout error messages in serial sections of the code. Both this solution and yours require some additional programming effort.

What I am looking for is just a plain simple output command, which can be used safely in parallel mex code.

[Walter Roberson]

The C programming language does *not* define printf() to be thread safe. The C programming language does not define anything about threads. There are different threading paradigms with different behaviors. One of the more common of those is POSIX Threads. POSIX might define the threading behavior of printf(), but C does not.

[Jan]

@Ilan: There is no simple way for output in multitreaded programs. Even simple logging and debug information need additional effort. A cheap solution could be to write in a (memory mapped) file and forward the file's contents to mexPrintf, when all threads have returned. But even this should be checked for beein thread-safe.

[Ilan]

@Walter: Of course I shouldnt have wrote just c. I am using c + openmp. What I meant is that in c + openmp printf is thread safe. I see this in my programs, and also the openmp tutorial by Chapman+Jost+Van Der Pas is full of examples with printf in parallel regions.

Answer 2

[Ilan]

I have checked this "workaround" in my code. It seems to work.

Specifically:

One way to print messages and data from within parallel regions in mex files written in c & openmp is the following.

Use fprintf(stderr,"...", variables) in the standard way. If the pragma starting the parallel region does not include the clause default(none) then stderr is available to all threads as a shared variable (stderr is of type * FILE). If you do have the default(none) clause then you need to pass stderr explicitly to the threads either via the shared() or firstprivate() clauses.

Note that this prints out to a terminal window (or wherever else you point stderr to). This can be very usefull for debugging parallel mex files written in c+openmp. Printing out to the matlab window is a different issue.