lkml.org 
[lkml]   [2000]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 12:45    [W:0.034 / U:0.064 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site