Messages in this thread | | | Subject | Re: [PATCH 5/8] locking, mutex: Cancelable MCS lock for adaptive spinning | From | Jason Low <> | Date | Tue, 25 Feb 2014 11:56:19 -0800 |
| |
On Mon, 2014-02-10 at 20:58 +0100, Peter Zijlstra wrote:
> +unqueue: > + /* > + * Step - A -- stabilize @prev > + * > + * Undo our @prev->next assignment; this will make @prev's > + * unlock()/unqueue() wait for a next pointer since @lock points to us > + * (or later). > + */ > + > + for (;;) { > + if (prev->next == node && > + cmpxchg(&prev->next, node, NULL) == node) > + break; > + > + /* > + * We can only fail the cmpxchg() racing against an unlock(), > + * in which case we should observe @node->locked becomming > + * true. > + */ > + if (smp_load_acquire(&node->locked)) > + return true; > + > + /* > + * Or we race against a concurrent unqueue()'s step-B, in which > + * case its step-C will write us a new @node->prev pointer. > + */ > + prev = ACCESS_ONCE(node->prev);
Should we also add an arch_mutex_cpu_relax() to this loop?
| |