Re: FCNTL Performance problem

[Chris Friesen]

On 08/11/2010 10:19 AM, Rob Donovan wrote:
> Hi,
> 
> Not sure it's about read or write 'priority' so much is it?
> 
> I wouldn't want to particularly favour writes over reads either, or it will
> just make the problem happen for reads wouldn't it?

No, because readers can always share the lock with other readers if
there is no writer waiting.

If you have one or more readers already holding the lock, with a writer
waiting, you have two choices:  1) let the new reader in under the
assumption that they'll be quick and won't extend the current "read"
usage by much, or 2) block the new reader until after any waiting
writers get a chance to get in.  The first is called reader priority,
the second is writer priority.

> And to do this, and make it favour writes, I presume it would have to be
> coded into the kernel to do this, there isn't any 'switch' for me to try?

The locks are written by glibc and the kernel.  I haven't looked at
fcntl locking so I'm not sure where the bulk of the code is.  I'd
suspect in the kernel.

> Could we not have it 'fairly' process locks? So that if a read lock comes
> along, and there is a write lock waiting for another read lock to unlock,
> then the 2nd read has to wait for the write lock. Not particularly because
> the write lock has priority, but because it was requested after the write
> lock was.

The behaviour you describe is called "writer priority".

> To me, it seems like there needs to be something in the fcntl() routines so
> that when a lock is called with F_SETLKW, if it gets blocked then it needs
> to put its 'request' in some kind of queue, so that if any more reads come
> along, they know there is already a lock waiting to get the lock before it,
> so they queue up behind it. 

Again, this would be implementing writer priority.

POSIX doesn't guarantee either form, so if you need a writer-priority
lock then fcntl() isn't a good choice.  In fact in most cases I suspect
you'll find that read/write locks are implemented as reader priority
since the expectation is that writes are infrequent.

Chris

-- 
Chris Friesen
Software Developer
GENBAND
chris.friesen@xxxxxxxxxxx
www.genband.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/