On Wed, Oct 8, 2014 at 9:35 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> 2) Implement the wait free LW_SHARED algorithm.
+ * too high for workloads/locks that were locked in shared mode very
s/locked/taken/?
+ * frequently. Often we were spinning in the (obviously exlusive) spinlock,
exclusive.
+ * acquiration for locks that aren't exclusively locked.
acquisition.
+ * For exlusive lock acquisition we use an atomic compare-and-exchange on the
exclusive.
+ * lockcount variable swapping in EXCLUSIVE_LOCK/1<<31-1/0x7FFFFFFF if and only
Add comma after variable. Find some way of describing the special
value (maybe "a sentinel value, EXCLUSIVE_LOCK") just once, instead of
three times.
+ * if the current value of lockcount is 0. If the swap was not successfull, we
successful.
+ * by 1 again. If so, we have to wait for the exlusive locker to release the
exclusive.
+ * The attentive reader probably might have noticed that naively doing the
"probably might" is redundant. Delete probably.
+ * notice that we have to wait. Unfortunately until we have finished queuing,
until -> by the time
+ * Phase 2: Add us too the waitqueue of the lock
too -> to. And maybe us -> ourselves.
+ * get queued in Phase 2 and we can wake them up if neccessary or they will
necessary.
+ * When acquiring shared locks it's possible that we disturb an exclusive
+ * waiter. If that's a problem for the specific user, pass in a valid pointer
+ * for 'potentially_spurious'. Its value will be set to true if we possibly
+ * did so. The caller then has to handle that scenario.
"disturb" is not clear enough.
+ /* yipeyyahee */
Although this will be clear to individuals with a good command of
English, I suggest avoiding such usages.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
