Re: Concurrency Issues
From: Nick Landsberg (hukolau_at_NOSPAM.att.net)
Date: 05/12/04
- Next message: Rich Teer: "Re: FILE* behaviour over BSD sockets - how?"
- Previous message: Aurelian Melinte: "FILE* behaviour over BSD sockets - how?"
- In reply to: Barry Margolin: "Re: Concurrency Issues"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 12 May 2004 18:30:46 GMT
Barry Margolin wrote:
> 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?
>
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
- Next message: Rich Teer: "Re: FILE* behaviour over BSD sockets - how?"
- Previous message: Aurelian Melinte: "FILE* behaviour over BSD sockets - how?"
- In reply to: Barry Margolin: "Re: Concurrency Issues"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
