Re: Concurrency Issues

From: Barry Margolin (barmar_at_alum.mit.edu)
Date: 05/12/04 

Date: Wed, 12 May 2004 10:57:00 -0400

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 ***

Relevant Pages

  • Re: ACID et al
    ... I'd say that if the 'system' must ascertain 3), then some kind of lock manager is needed. ... And I'm not saying there isn't, as most synchronization methods used today are probably generalizations of lessons learned the hard way. ... another one is that i think it's a fallacy to imagine that one can write an app for concurrent users, let alone concurrent transactions without thinking through how their different purposes might clash, no matter how well the db engine in question is marketed! ...
    (comp.databases.theory)
  • Re: [PATCH] mm: PageLRU can be non-atomic bit operation
    ... what of concurrent operations changing other bits in that same ... unsigned long e.g. trying to lock the page by setting PG_locked? ... on an SMP machine, without the lock prefix, the operation ... one or the other of the racing operations. ...
    (Linux-Kernel)
  • Re: [patch 1/6] Guest page hinting: core + volatile page cache.
    ... Concurrent page state changes: ... To guard against concurrent page state updates some kind of lock ... lock, or lock per segment in the kernel page table, or the per page ...
    (Linux-Kernel)
  • Re: ReadWriteLock rather on maps each field than whole map?
    ... so there is no real "concurrent" putposible. ... You haven't sad what kind of lock. ... maybe could make a difference when the cache is initially empty. ...
    (comp.lang.java.programmer)
  • Re: [PATCH 0/1] SIGWINCH problem with terminal apps still alive
    ... Alan Cox wrote: ... race because of rescheduling so lock is not working here. ... Adam, since you are working on this issue, I'd suggest you modify the source ...
    (Linux-Kernel)