Unix Programming - Concurrency Issues

Author

Concurrency Issues

Xarky

2004-05-12, 9:08 pm

Hi,
I am writing a small program, where any number of users can have
access to a file apparently concurrently. Since certain operations
done on the file such as ADD at EOF, Modify, Delete, make rise to race
conditions, I designed a small algorithm to ensure that only one user
is using the file at one time. Basically I share a variable between
all users and when a user requests an operation, user checks its value
and upon its value, he acts.

But by using the algorithm designed, I have lost the concurrency
aspect. Is there a way to let users use the file apparently
concurrently and avoiding the problem of race conditions?

I hope I was clear in my explanation.

Thanks for your help

Barry Margolin

2004-05-12, 9:08 pm

In article <bc42e1a.0405120624.1a40b791@posting.google.com>,
bernardpace@yahoo.com (Xarky) wrote:

> Hi,
> I am writing a small program, where any number of users can have
> access to a file apparently concurrently. Since certain operations
> done on the file such as ADD at EOF, Modify, Delete, make rise to race
> conditions, I designed a small algorithm to ensure that only one user
> is using the file at one time. Basically I share a variable between
> all users and when a user requests an operation, user checks its value
> and upon its value, he acts.

Why don't you use file locks or semaphores?

>
> But by using the algorithm designed, I have lost the concurrency
> aspect. Is there a way to let users use the file apparently
> concurrently and avoiding the problem of race conditions?

Whenever concurrent applications use a shared resource, they have to
perform some kind of mutual exclusion to prevent races. There's no way
to get absolute concurrency, all you can do is minimize the size of the
critical regions where you access to the shared resource, which should
minimize the amount of waiting that takes place when two processes try
to access it.

If you use file locking, the lock can be specific to a particular
section of the file. So process 1 can lock bytes 10-20, and process 2
can lock bytes 100-120, and they each can then modify their portion of
the file without interfering with each other?

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Nick Landsberg

2004-05-12, 9:08 pm

Barry Margolin wrote:
> In article <bc42e1a.0405120624.1a40b791@posting.google.com>,
> bernardpace@yahoo.com (Xarky) wrote:
>
>
>
>
> Why don't you use file locks or semaphores?
>
>
>
>
> Whenever concurrent applications use a shared resource, they have to
> perform some kind of mutual exclusion to prevent races. There's no way
> to get absolute concurrency, all you can do is minimize the size of the
> critical regions where you access to the shared resource, which should
> minimize the amount of waiting that takes place when two processes try
> to access it.
>
> If you use file locking, the lock can be specific to a particular
> section of the file. So process 1 can lock bytes 10-20, and process 2
> can lock bytes 100-120, and they each can then modify their portion of
> the file without interfering with each other?
>

What Barry said is absolutely true.

If you are using a single flag for the whole file
you have a locking granularity at the file level, i.e.
"file locking".

If there are some long-lived operations, say on the
order of several seconds, then
you lose the appearance of concurrency. Barry's
suggestion can be described as "record locking."
This presupposes (in a very simplistic sense)
that each record is a fixed length and that a
"modify in place" does not create a longer
length record and thus force you to rewrite all
later records in the file.

Using either method you must still consider
*when* you apply the lock. For example, if
user A reads a record and *may* want to modify
it, should you take out the lock at the time
the record is read, or at the time the user
wants to modify it? If the former, you may
lock out all other users from the record if
user A goes on a coffee break. If the latter,
the record may have already been modified by
user B after user A read it but before user A
modified it. Life gets complicated around this
time, and there is no one right answer for all
applications. Think about it and make your
own decisions, but be sure to have a reason
for the decision.

HTH.

NPL.

--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch

Sponsored Links