Concurrent access and locks

I'm developing a collaborative application in PHP which accesses
local files and may modify them. How can I synchronize the multiple
accesses? Note that I'm not worried about the algorithmic part of the
problem, or how to avoid conflicts, which I know how to solve; I just
need a few atomic primitive shared among any PHP processes that may be
running. I could even have a separate process serializing all operations
if such a thing is possible. flock() seems to be too limited for my needs.
Thanks a lot,

--
Bruno Barberi Gnecco <brunobg_at_users.sourceforge.net>
http://www.lsi.usp.br/~brunobg/

What about flock() is too limited for your needs?

ZeldorBlat wrote:
> What about flock() is too limited for your needs?

Doesn't work over NFS and other FSs, is slow, does not
let me lock directory hierarchies (which is important for atomically
changing many files at once) or even many files atomically.

--
Bruno Barberi Gnecco <brunobg_at_users.sourceforge.net>
http://www.lsi.usp.br/~brunobg/

Hello,

on 04/03/2005 11:35 AM Bruno Barberi Gnecco said the following:
> ZeldorBlat wrote:
>> What about flock() is too limited for your needs?
>
> Doesn't work over NFS and other FSs, is slow, does not

Not true. That is only a problem of some implementations.

If you are concerned with speed, you should not be using NFS anyway.


> let me lock directory hierarchies (which is important for atomically
> changing many files at once) or even many files atomically.

flock is exactly for what you need. If you want to change many files
with a single lock, you can pick a special file and lock it when you
want to access or change many files.


--

Regards,
Manuel Lemos

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

PHP Reviews - Reviews of PHP books and other products
http://www.phpclasses.org/reviews/

Metastorage - Data object relational mapping layer generator
http://www.meta-language.net/metastorage.html

mlemos wrote:

>>> What about flock() is too limited for your needs?
>> Doesn't work over NFS and other FSs, is slow, does not
> Not true. That is only a problem of some implementations.
> If you are concerned with speed, you should not be using NFS anyway.

I'm not using it, but I wanted to support it. Let's not into
another "why NFS sucks" thread because I think we all agree with that :)

>> let me lock directory hierarchies (which is important for atomically
>> changing many files at once) or even many files atomically.
> flock is exactly for what you need. If you want to change many files
> with a single lock, you can pick a special file and lock it when you
> want to access or change many files.

Sorry, but I can't see how that solves the problem. If I create
a file containing the names of the locked files and lock it, there's
still the possibility of racing. If I use just one file for all
processes, listing all locked files, how can I know when a certain
file is unlocked?

--
Bruno Barberi Gnecco <brunobg_at_users.sourceforge.net>
http://www.lsi.usp.br/~brunobg/
It is easy when we are in prosperity to give advice to the afflicted.
-- Aeschylus

Hello,

on 04/03/2005 06:18 PM Bruno Barberi Gnecco said the following:
>>>> What about flock() is too limited for your needs?
>>> Doesn't work over NFS and other FSs, is slow, does not
>> Not true. That is only a problem of some implementations.
>> If you are concerned with speed, you should not be using NFS anyway.
>
> I'm not using it, but I wanted to support it. Let's not into
> another "why NFS sucks" thread because I think we all agree with that :)

NFS does not suck. Files under NFS are remotely stored and you must deal
with the network access overhead. That could be useful in many
circumstances on which such overhead is bearable.

Your inconsistent is that while you claim flock is slow (I don't know
where did you get this idea), you are not concerned with supporting NFS
when it is much slower due to network overead.


>>> let me lock directory hierarchies (which is important for atomically
>>> changing many files at once) or even many files atomically.
>> flock is exactly for what you need. If you want to change many files
>> with a single lock, you can pick a special file and lock it when you
>> want to access or change many files.
>
> Sorry, but I can't see how that solves the problem. If I create
> a file containing the names of the locked files and lock it, there's
> still the possibility of racing. If I use just one file for all
> processes, listing all locked files, how can I know when a certain
> file is unlocked?

You can use shared locks for reading and exclusive locks for writing.


--

Regards,
Manuel Lemos

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

PHP Reviews - Reviews of PHP books and other products
http://www.phpclasses.org/reviews/

Metastorage - Data object relational mapping layer generator
http://www.meta-language.net/metastorage.html

mlemos wrote:

>> I'm not using it, but I wanted to support it. Let's not into
>> another "why NFS sucks" thread because I think we all agree with that :)
> NFS does not suck. Files under NFS are remotely stored and you must deal
> with the network access overhead. That could be useful in many
> circumstances on which such overhead is bearable.

NFS has several known problems. It has an awful lag (not due to
the network overhead, but to its caching), lack of a safe lock/unlock
system to avoid inconsistency, etc...

> Your inconsistent is that while you claim flock is slow (I don't know
> where did you get this idea),

The web. Since I may have to lock several hundred files in
some operations, I was worried when I read that flock was slow.
Now, if someone is running it on NFS, they are probably likely
to have a small number of files or know the potential problems.

>> Sorry, but I can't see how that solves the problem. If I create
>> a file containing the names of the locked files and lock it, there's
>> still the possibility of racing. If I use just one file for all
>> processes, listing all locked files, how can I know when a certain
>> file is unlocked?
> You can use shared locks for reading and exclusive locks for writing.

I still can't get it.
From what I understood of your solution, I could keep a separate
metafile with entries for all files that are currently "locked", and flock
only this file. Suppose now that process A locks "file1" for reading, and
process B wants to write to "file1". Do I need to stat the metafile
manually every N milliseconds to check when process A released the lock?

--
Bruno Barberi Gnecco <brunobg_at_users.sourceforge.net>
http://www.lsi.usp.br/~brunobg/
It is easier to fight for one's principles than to live up to them.
-- Alfred Adler