Re: mutex vs turnstile

[Nick Hudson <skrll%netbsd.org@localhost>]

On 01/09/18 03:30, Mateusz Guzik wrote:
> Some time ago I wrote about performance problems when doing high -j
> build.sh and made few remarks about mutex implementation.
>
> TL;DR for that one was mostly that cas returns the found value, so
> explicit re-reads can be avoided. There are also avoidable explicit
> barriers (yes, I know about the old Opteron errata).
>
> I had another look and have a remark definitely worth looking at (and
> easy to fix). Unfortunately I lost my test jig so can't benchmark.
>
> That said, here it is:
>
> After it is is concluded that lock owner sleeps:

itym... after it is concluded that the thread should sleep as the lock 
is owned (by another lwp) and the owner is not on cpu.

>          ts = turnstile_lookup(mtx);
>          /*
>           * Once we have the turnstile chain interlock, mark the
>           * mutex has having waiters.  If that fails, spin again:
>           * chances are that the mutex has been released.
>           */
>          if (!MUTEX_SET_WAITERS(mtx, owner)) {
>                  turnstile_exit(mtx);
>                  owner = mtx->mtx_owner;
>                  continue;
>          }
>
> Note that the lock apart from being free, can be:
> 1. owned by the same owner, which is now running
>
> In this case the bit is set spuriously and triggers slow path
> unlock.

Recursive locks aren't allowed so I don't follow what you mean here.

    544         if (__predict_false(MUTEX_OWNER(owner) == curthread)) {
    545             MUTEX_ABORT(mtx, "locking against myself");
    546

> 2. owned by a different owner, which is NOT running

Is this still a possibility given the above?

Nick