On Wed, Oct 8, 2014 at 9:35 AM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
