Hi All,

I am going through the semaphore concept and have a doubt regarding the same and hope to get a resolution here.

I have a file which has a number of records.
I want to write an application (in C) which will be able to do concurrent read/write on these records.

Of what I have understood about semaphores, I know that a process can obtain a lock on the critical section of code, read/write into records, then release the lock so the other processes waiting to access the data can obtain a lock.

I am confused and tend to think that "Wouldn't this concept lead to a more serious problem?" as another process, actually wanting to read/write a different record on the same file has to wait for the lock to get released by the process which has obtained the lock. If this is the case, think of a situation where we have a large number of processes (say, more than 1000) wanting to do a read/write on same/different records. Wouldn't this concept slow down the application?

Please let me know if I have misunderstood the concept and throw some light on this...

Regards
maverix

You don't say what UNIX you are on but consider file locks instead of semaphores.

start with 'man flock' if you're on Linux.
Otherwise, man fcntl, then look for FD_SETLK or FD_GETLK to start off.

Depending on your OS you can get file locks at different levels; struct flock can provide locking a part of a file.

Semaphores are mostly used for access to shared memory.

Semaphores are not inherently linked to memory, processes, code or files.

Semaphores are flags that processes, including processes that access files or shared memory, use to know a guaranteed status, which is often referred to as "atomic".

Let's say you are writing a shared memory application. You don't want to read or write to shared memory when another process is writing to it (if that process has write permissions). Also, you don't want to read a file that is being changed, etc. So, you create a semaphore and you designate two states:

- semaphore set, means that a process with write permission has a file descriptor open.

- semaphore clear, means that there is no process with write permissions accessing the shared memory.

Now, each process that accesses the shared memory must check the status of the semaphore when they (it) open the file (in this case shared memory) for access.

There are many applications for semaphores for interprocess communications, not limited to shared memory; but shared memory certainly required atomic flags for interprocess communications.

Think of this like a person on a single track of train track holding a flag. One train is flying down the track at 200 kph in one direction and other train is heading toward the same track segment from the opposite direction. There is a switch at one section of track where one train can wait while the other passes. A switchman, in the old days, would hold up a flag (later done with lights) to give status to both trains.

You can see that trusting the flags by the switchman is critically important, folks could dies if the flag is incorrect or the conductor of the train does not watch it.

The same is true in interprocess communications, and semaphores are guaranteed by the UNIX / Linux kernel to be atomic, dead right on.

File locks are not guaranteed by the kernel to be atomic, as I recall, so use them with caution.

Hi Jim and Neo,

Thank you for your replies...

I am using RHEL 4.
I have used lockf() and flock() system calls and it seems to work fine.

However, I want to use semaphores to get the same effect. FYI...I am doing these just to understand and learn the concepts. Its not a live/industry project.

Using lockf() and flock(), I was able to lock certain sections of files depending on the file position we provide. Say, for example, the application is a simple banking application and the database I use is a simple file which has number of records which contains account information. Using lockf(), I was able to lock a certain record by obtaining the account number from the user so that another process wanting to access a different record didn't have any issues in reading/writing to a different record.

My question was how to get the same effect using semaphores. If the number of concurrent processes are more, then each process will be waiting to obtain the semaphore to enter the critical section of code, isn't that so?

regards
maverix

I think the wikipedia entry on Semaphore programming answers your question.....

One thing to be aware of is the type of thing you are guarding determines the type of semphore.

If it's a file, then file locking is preferred, this way even if the file is on a NFS volume, the locking and sharing will still work.

If the thing is in a single process and the sharing is between threads then using pthread_mutex/pthread_cond et al.

If the thing is shared memory or similar that is being shared by processes that are on the same machine then you can use the kernel provided semahores.

I suggest reading anything by W.Richard Stevens on the subject.

Hi All,

Thank you for your inputs.

As suggested by porter, I think I'll have to settle with file locking mechanisms as I am using a simple file.

Let me explore other IPC facilities (yet to start studying :-) ) and will get back to you guys with more doubts...

regards
maverix