As others have said, it is never necessary to sleep() to cause file operations to work consistently.   You should write to the file, using an exclusive mode (because you do not want readers to see incomplete results).   Then, you should close the file and reopen it for reading.   This will assure consistency, both to your own program and to any other one(s).   If both of these processes are being done in the same program, the same file-handle can simply continue to be used.

If you are attempting to read from a file that is concurrently open for writing, unpredictable results (called dirty reads) may result.

On another note ... “call me an old COBOL hound, but” ... I do come from a day when main-memory was quite small in relation to the quantity of data that you need to process, so I always do such things using intermediate “spill files,” not in-memory stashes.   For one thing, I know that “memory” is really a disk-file, and for another, I know that many (esp. desktop-sized even-if rack-mounted) systems really don’t handle memory-pressure very well at all:   they start to “thrash” at the drop of a hat.   (Especially when dealing with programs that are using in-memory stashes, which are inherently thrash prone.)   But their operating systems handle file-buffering quite sensibly:   they’ll give “unused” memory over to file buffers without being told to do so, and they’ll handle reductions in the amount of memory that is available for that purpose much more graciously than they will handle any application that has suddenly become a million-pound elephant.   So, I’ll read the data from one file and copy it into another.   When asked to sort information, I’ll do on-disk sorts instead of in-memory ones.   I have plenty of experience to tell me that such programs really don’t run slower in the small case (thanks to the buffering), and that they degrade much more gracefully (linearly ...) as the data load grows large.   I basically get to have my cake and eat it too.