Re: rmlock question..

Darren Reed wrote:
Stephan Uphoff wrote:
Julian Elischer wrote:
Julian Elischer wrote:
If I make an exclusive rmlock request on an rmlock that has a busy set of readers coming and going, do new readers wait for me to get
my turn, or do I have to wait for a moment where there are no more readers before I get a go?
in fact if the requests are of the order

reader, reader, writer, reader, reader, writer, reader

is the order of evaluation defined? is it preserved?
This is a bit of a tricky question to answer.
...
So in your example the first writer (W1) will be blocked by the first two Readers (R1,R2)
but will disable the read fast path and hold the internal mutex.
W1 will block R3,R4,W2,R5 as they all need to acquire the internal mutex.
If R1,R2 release the lock, W1 will become unblocked and eventually unlock the lock
such releasing the mutex. At this time R3,R4,W2,R5 compete for the mutex and whoever
wins is next in the locking order.

Sorry for the delay in answering.
Somehow your post did not make it to my inbox.
Is there is a chance that so long as there is more than one Reader
waiting for a mutex, a Write lock request may never be granted?
No. Even if all reader waiting for the mutex have a higher priority and need
to acquire the mutex for a short time no new readers will need the mutex as long
as the readlock fastpath is enabled. The reader fastpath is only disabled
once the writer holds the mutex.

Given the name "read mostly", is there any favouritism towards
Readers vs Writers when competing for the mutex?
No the name is derived from the fact that the lock is designed to work mostly
in a state where the reader fastpath can be used.
Using the fastpath the shared lock can be acquired without any atomic operations or
dirtying of shared cache lines.

Or conversely, if there is always a pending Write request that a
read is never granted?

Yes - if there is always a write request and the write threads always
have better priority than the read request.
But then you really, really have picked the wrong lock.
( And you would have the same problem just using a mutex)
When R3,R4,W3,R5 compete for the mutex, if R3-5 wins, is
the read fast path enabled again?

I assume you mean R3, R4, W2, R5

Yes - however none of R3-5 will be retried using the fastpath.
( All need to acquire the mutex)
If any of the Readers wins, does this mean that all Readers are
dequeued, or only those upto the pending Write?
No - if a reader wins it enables the fastpath - but currently blocked readers
are not on the fastpath and still need to acquire the internal mutex.
In this case R3, R4, will acquire the mutex for a short time.
Then W2 will acquire the internal mutex and wait for R3,R4 to release the read lock.
Once W2 release the write lock (and as such the internal mutex) R5 will be
unblocked and can acquire the internal mutex.
Actually it is not quite as deterministic as lock order on mutexes is not
that strictly enforced.
This may change in the future if I replace the internal rmlock
mutex with lower level primitives.
Right now rmlock is in a state where only the read fastpath is really optimized.
The rest is functional complete but I expect some tuning to happen once we
have more experience with situations where rmlocks are useful.

Stephan
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: duplicate read/write locks in net/pfil.c and netinet/ip_fw2.c
    ... > the reader does not hold the lock. ... >> which breaks when we try to RLOCKwith other mutex already acquired. ... > but that is not a solvable problem given that the *LOCK may be blocking. ... Keeping track of all readers requires pre-allocated memory resources. ...
    (freebsd-arch)
  • Re: duplicate read/write locks in net/pfil.c and netinet/ip_fw2.c
    ... > the reader does not hold the lock. ... >> which breaks when we try to RLOCKwith other mutex already acquired. ... > but that is not a solvable problem given that the *LOCK may be blocking. ... Keeping track of all readers requires pre-allocated memory resources. ...
    (freebsd-net)
  • Re: pthread_mutex problem
    ... > idea is to have two threads and a buffer. ... > So when the writer wants to write, it locks the write mutex. ... > get here is that the writer writes one time, then the reader reads one ...
    (comp.os.linux.development.apps)
  • Re: pthread_mutex problem
    ... > I am trying to make a multithreaded reader/writer app using pthread. ... > So when the writer wants to write, it locks the write mutex. ... and when it's done it unlocks the write mutex again. ... > get here is that the writer writes one time, then the reader reads one ...
    (comp.os.linux.development.apps)
  • Re: pthread_mutex problem
    ... > I am trying to make a multithreaded reader/writer app using pthread. ... > So when the writer wants to write, it locks the write mutex. ... and when it's done it unlocks the write mutex again. ... > get here is that the writer writes one time, then the reader reads one ...
    (comp.os.linux.development.apps)