[svn-r4997] Purpose:

Bug Fix
Description:
	So, for Raw I/O in parallel, if you open a file with truncation by
	multiple processes, it looks as if one process could open the file
	and start writing to it while another process also opens the file
	with truncation, thus wiping out all of the stuff the first process
	wrote to the file.

	This is bad.

	Also added some garbage collection to the pio_perf routine to reclaim
	the space taken by some of the tables.
Solution:
	Placed an MPI_Barrier() statement after the Raw open()/create() call
	so that all processes are synced up before they start writing to the
	file.

	Added free() calls to the tables which weren't being free'd.
Platforms tested:
	Linux-pp (eirene)

perform/pio_engine.c

@@ -926,6 +926,16 @@ do_fopen(iotype iot, char *fname, file_descr *fd /*out*/, int flags)
         else
             fd->rawfd = RAWOPEN(fname, O_RDONLY);
 
+        /* The perils of raw I/O in a parallel environment. The problem is:
+         *
+         *      - Process n opens a file with truncation and then starts
+         *        writing to the file.
+         *      - Process m also opens the file with truncation, but after
+         *        process n has already started to write to the file. Thus,
+         *        all of the stuff process n wrote is now lost.
+         */
+        MPI_Barrier(pio_comm_g);
+
         if (fd->rawfd < 0 ) {
             fprintf(stderr, "Raw File Open failed(%s)\n", fname);
             GOTOERROR(FAIL);

perform/pio_perf.c

@@ -583,8 +583,11 @@ run_test(FILE *output, iotype iot, parameters parms)
     output_report(output, "Average Throughput: %.2f MB/s\n",
                   total_mm.sum / total_mm.num);
 
+    /* clean up our mess */
     free(write_mm_table);
     free(read_mm_table);
+    free(write_gross_mm_table);
+    free(read_gross_mm_table);
     pio_time_destroy(res.timers);
     return ret_value;
 }