How to apply concurrent read and write operation on a text file from two different program in c

Question

I am writing on a text file from one application and another application is reading from it.Is it necessary to use semaphore or file lock while reading and writing?

I have searched in google and found that some said synchronization is required.If synchronization is required which one is preferable between semaphore or file lock.

writing file from one application.

    fp = fopen(status_info_dir, "w");

    if (fp)
    {
        for (i = 0; i < USER_NUMBER; i++)
        {
            CurrentUser = userArray[i];

            if (CurrentUser)
            {
                fprintf(fp, "Usr indx: %d, %s, IP:%s\n",
                        i, CurrentUser->macAddress, CurrentUser->ipAddress);
            }
        }

        fclose(fp);
    }

   //reading file from another application and find sometimes data loss 
   //while reading.

    while (fgets(statusFileInfo, 255, fp) != NULL)
    {
       if (strcmp(statusFileInfo, "\n") == 0)
           continue;
       printf("%s\n", statusFileInfo);
    } 

Answer 1

Is it necessary to use semaphore or file lock while reading and writing?

Not necessarily, but it is likely that you will need some form of synchronization.

If synchronization is required which one is preferable between semaphore or file lock.

It depends on what you need to do and your environment. There are many ways to perform IPC and synchronize processes.

If you are under Linux as the tag suggests, you only care about local filesystems and you want a reasonably simple solution, then try file locking, eg with lockf ; perhaps taking advantage of sections if needed.

Answer 2

If your shared resource is data in a file, it seems more natural to use file locking, as it allows you to define and protect a file region (between to byte offsets in the file) and you can lock for reading (allowing multiple readers to access) or writing (with exclusive locks). And file locking works over NFS, so you can lock files that are accessed through the network transparently (semaphores need to be in the same machine as all the processes that are involved in the shared resource) Also, with file locking you don't need to get extra resources (as the semaphores in the other alternative) as everything is done through the file descriptor of the file you are going to access.

As you don't tell us the type of access you are going to do, I cannot say much more... but there's a third case of interest that you have not mentioned, but can be the solution also if some conditions meet: If one process is reader, and other process is writer, and you are using the file just to pass data from one process to the other, perhaps the pipe is the best alternative.... as it blocks the reader while the writer has nothing to say, it blocks the writer if the reader is not ready to process more data, and doesn't grow indefinitely, as would be the case in case you plan to comunicate huge amounts of data between both.

If you need bidirectional communication, the solution then should be the unix socket. On this, both processes acquire a socket each. They connect both sockets, and then they can read or write on their socket. What they write, is readed from the other socket by the other process. What they read, is comming from the written data on the other socket.

Semaphores in Linux are derived from At&t UNIX SysV semaphores and have a little difficult to learn interface (I have read books in which authors fail blatantly to describe how to use them, because the API is so complex) Semaphores are acquired in arrays (several semaphores per request) and to allow unblocking in case a process dies, you can program them to undo all the locks they have made to the semaphore. Once you get reading the man pages you'll probably decide to use another alternative.

Anyway, you need to know that file locking is never mandatory, your process gets blocked when trying to access the shared region, but only if you call the locking call, if you are to run your program with some other program that is unaware of the locking mechanism, then access will not be einforced by the kernel and you'll end in a mess.

So that's all, folks!