|
Home > Archive > Unix Programming > August 2007 > multi-process locking
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
multi-process locking
|
|
| Ivan Novick 2007-08-29, 1:20 pm |
| Hi,
>From people's experience, what do you think is the best technique for
locking a shared resource between multiple processes? I have seen
people use the file system and even some people use a oracle DB.
Thanks,
Ivan Novick
http://www.0x4849.net
| |
| Rainer Weikusat 2007-08-29, 7:26 pm |
| Ivan Novick <ivan@0x4849.net> writes:
> locking a shared resource between multiple processes? I have seen
> people use the file system and even some people use a oracle DB.
This depends on how you define 'best'. A property I would consider
essential is that there must never be a 'stale lock', meaning if the
process owning the ressource now dies for any reason, the however
implemented lock must be released automatically. This rules out all kinds
of locking done by means of existance or non-existance of a
particular file[*].
Especially if the 'shared ressource' is actually a file, I usually use
POSIX record locks.
| |
| Chris Friesen 2007-08-29, 7:26 pm |
| Ivan Novick wrote:
> locking a shared resource between multiple processes? I have seen
> people use the file system and even some people use a oracle DB.
This is a tricky issue to handle really well.
fcntl() (aka record locks) are automatically freed if the holding
process exits. This is both good and bad--it's good because someone
else can take the lock, it's bad because the resource could be in a
non-consistent state. If you use this type of lock, you should make
sure that resource consistency is verified somehow--checksums on shared
data, for instance.
Depending on your OS, you could also use process-shared pthread mutexes.
These may be faster than the fcntl() locks, but will not be freed on
process death, unless you also use the "robust" version.
In either case, if corruption in the shared resource is detected, you
need to have some form of reinitialization strategy.
Chris
| |
| Rainer Weikusat 2007-08-29, 7:26 pm |
| Chris Friesen <cbf123@mail.usask.ca> writes:
> Ivan Novick wrote:
>
>
> This is a tricky issue to handle really well.
>
> fcntl() (aka record locks) are automatically freed if the holding
> process exits. This is both good and bad--it's good because someone
> else can take the lock, it's bad because the resource could be in a
> non-consistent state.
It is 'bad' when a processes crashes, leaving 'some shared ressource
in a non-consistent state'. And this badness doesn't get less bad by
forcing someone who hopefully knows about the traditional UNIX(*)
adversary to even barely robust locking schemes to intervent manually
before even detecting that the 'shared ressource is in an inconsistent
state' is possible.
|
|
|
|
|