I don't object to flock() at all. It does what it claims to do, but using it incorrectly can be the problem. A race condition is when you have this type ofrun of events which is somewhat common, especially in older scripts (I have seen this a lot in CGI scripts):

1. Open FH for reading
2. Lock FH
3. Read FH
4. Close FH
5. Re-open FH for writing
6. Lock FH
7. Write to FH
8. Close FH

Here you should be able to see the race. Another process can get an exclusive lock on the FH during the read open (read-only opens don't generally get exclusive locks), and between the close of the read and open of the write. Hence, you can have multiple processes working on the file in a way you do not want which could currupt your data ("Hey! Why is my counter file suddenly blank??").

Consider this flow:

1. Proc A open FH for write (using > which clobbers the file contents)
2. Proc B opens FH for reading (no lock attempt since it won't likely get an exclusive lock granted)
3. Proc A locks FH
4. Proc A works with FH
5. Proc A closes FH

One race concern here is that if another process wants to read the contents of this file, it will get garbage since proc A clobbered the file contents. Having proc B attempt an exclusive lock is futile since they are not generally granted to r/o opens. By using semaphores, you can avoid this situation.

These are just two examples (there is also an issue of hardware physically not being done writing to disk before another process opens the file). A good idea is to write the flow of your locks on a whiteboard and see what would happen if multiple processes are doing that same flow at once (I generally add sleeps at key points to show myself this, like in the example script in node 14140.

I hope this makes more sense, if not let me know.

Cheers,
KM