Initiate 2-phase I/O

ss_blob_synchronize is a function defined in ssblob.c.

Synopsis:

herr_t ss_blob_synchronize(ss_scope_t UNUSED_SERIAL *topscope, ss_prop_t UNUSED_SERIAL *props)

Formal Arguments:

Description: When a task has a buffer of data to be written to the file it can do so either synchronously or asynchronously. The benefits of asynchronous writes are: (1) separate write requests from a task destined for a single dataset can be combined into a single H5Dwrite call, (2) data from many tasks can be aggregated into larger amounts before the H5Dwrite calls occur, and (3) at least part of the process of getting the data to disk can be overlapped with other computation.

Any task can make independent requests for asynchronous writes, and a collective call to this function causes tasks to agree on how the data transfer will occur and to initiate the asynchronous transfers of data to chosen aggregation tasks. After this function has been called all data will either be on disk or in the process of moving to disk. Therefore it is not safe yet for the client to free its buffers and will not be safe until a call to ss_blob_flush.

All blobs for the file of the specified top scope are synchronized unless the “dset” property of props is specified, in which case it should be a dataset handle to indicate the one and only dataset to synchronize.

Return Value: Returns non-negative on success; negative on failure.

Parallel Notes: File collective across the communicator for topscope. File collectivity is necessary in order to meet HDF5 API requirements for H5Dextend and because multiple blobs from different scopes using different communicators can share a single dataset (the one thing they all have in common is the file).

Serial behavior is a no-op.

Issues: In order to assure correct order of I/O operations it is imperative that all I/O for a particular HDF5 dataset be either synchronous or asynchronous. SSlib doesn’t check for mixed mode requests but it probably should.

This function makes no attempt to combine separate write requests from a single task into a single request.

The data shipping code uses MPI async p2p functions even when the source and destination are the same task.

This function does not attempt to optimize the case when ss_blob_write was called with the SS_ALLSAME bit flag. When this bit is set all blob tasks will have called ss_blob_write with identical data and offsets and it may therefore be the case that an aggregation task has the data already available locally.

Lots of error-related stuff needs to go here!

See Also: