: Assume, for instance, that you have a database with lots of readers but=
: few
: writers. Any update will temporarily leave the database in an inconsist=
: ent
: state. You therefore need locking. With advisory locks, every reader mu=
: st
: lock-read-unlock every piece of data it accesses, thereby requiring thr=
: ee
: times as many system calls.
It is interesting idea.
But it would mean, that any read operation should create implicit lock.
Linux does not make it (look at sources),
so that you could not make any locking with the same result.
Is it Linux bug? Solaris-2.3 has it too, anyway.
In any case, Stevens measured, that setting advisory locks adds 15% of time,
and enabling mandatory locks eats another 15% (in read/write ops.).
If you will not call fcntl(.,SETLK.,.), you will take 15% back and
got no profit.
: > for SYSV IPC semaphores and message queues.
You are right, SYSV IPC was invented before reliable signals,
before STREAMS, before sockets ... Only half-duplex pipes existed
at this time.
It is very old and mature interface.
BEWARE! Flame follows:
But msg queues were obsoleted by STREAMS.
SYSV IPC semaphores are about to be obsoleted by POSIX.4.
etc. etc.
The fact, that linux kernel incorporates all this obsolete garbage,
does not mean that it becomes more universal, that it becomes more
compatible with SYSV.
My personal opinion: it only increases kernel size and decreases
performance, not more.
We could compare linux and UNIX only after implementing STREAMS and
other really great SYSV inventions, in any case.
Now they are the creatures from different worlds.
Please, do not flame me back.
Alexey Kuznetsov.