Messages in this thread | | | Date | Sun, 05 Nov 2000 10:57:57 +1100 | From | Andrew Morton <> | Subject | Re: Multithreaded locks.c |
| |
Alan Cox wrote: > > > have got it right. Does anyone know what this part of the > > flock(2) manpage means? > > > > A single file may not simultaneously have both shared and > > exclusive locks. > > AFAIK its saying LOCK_EX is exclusive and blocks shared locks and vice > versa. Its a standard reader-writer lock setup. LOCK_EX is writer, LOCK_SH > is reader.
Thanks, Alan. You're right, and this is indeed how the current implementation behaves. The DG/UX manpage makes a bit more sense here.
One interesting factoid: if a process currently has an exclusive lock, and it changes that to an exclusive lock (ie: no change), this has the effect of dropping the lock and reclaiming it.
The DG/UX dg_flock() departs from BSD in that "Upgrading a lock will be an atomic operation. That is, a lock is not released to upgrade that lock". Linux doesn't do that - the lock is effectively dropped and reclaimed when we go from LOCK_SH to LOCK_EX.
Even the DG/UX manpage doesn't say what happens when you sidegrade the lock. LOCK_EX->LOCK_EX :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |