I know this is ages old, but in case someone runs into this. IMHO the way to go about it is like this:
1) Open the original file (e.g. original.txt) using file_get_contents('original.txt').
2) Make your changes/edits.
3) Use file_put_contents('original.txt.tmp') and write it to a temp file original.txt.tmp.
4) Then move the tmp file to the original file, replacing the original file. For this you use rename('original.txt.tmp', 'original.txt').
Advantages: While the file is being processed and written to the file is not locked and others can still read the old content. At least on Linux/Unix boxes rename is an atomic operation. Any interruptions during the file writing don't touch the original file. Only once the file has been fully written to disk is it moved. More interesting read on this in the comments to http://php.net/manual/en/function.rename.php
Edit to address commments(too for comment):
https://stackoverflow.com/questions/7054844/is-rename-atomic has further references to what you might need to do if you are operating across filesystems.
On the shared lock for the reading I am not sure why that would be needed as in this implementation there is no writing to the file directly. PHP's flock (which is used to get the lock) is a little but unreliable and can be ignored by other processes. Thats why I am suggesting using the rename.
The rename file should ideally be named uniquely to the process doing the renaming so as to make sure not 2 processes do the same thing. But this of course does not prevent editing of the same file by more than one person at the same time. But at least the file will be left intact (last edit wins).
Step 3) & 4) would then become this:
$tempfile = uniqid(microtime(true)); // make sure we have a unique name
file_put_contents($tempFile); // write temp file
rename($tempfile, 'original.txt'); // ideally on the same filesystem
array.insert is O(n) for insertions in the middle (because it has to copy a part of the array), making the second variant O(n^2), while push is O(1), and sort! is O(n log n), so the first variant is only O(n log n). Also the first variant looks cleaner.
Best Answer
You didn't mention if it matters what order the output is in. If it really doesn't matter I'd use a single-threaded Queue to receive messages from multiple reader/processor threads. Then another thread could be in charge of reading from the Queue and writing to the output file.
If order matters then your #2 seems a good idea.
I am concerned that with your suggestions #1 and #3 that if one is not very careful with the locking around the shared output object (file pointer or array) that one would be in 'undefined behavior' territory.