Re: [PATCHv2] attr: convert to new threadsafe API

From: Stefan Beller <sbeller@google.com>
Date: Oct 12, 2016, 21:42 UTC
Message-ID: <CAGZ79kb-xKDNG-LC56i8Y-FAaYZwr8zzXuC9snj1PavnQ6cdCA@mail.gmail.com>
In-Reply-To: <xmqq8ttt2qpp.fsf@gitster.mtv.corp.google.com>

On Wed, Oct 12, 2016 at 2:38 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 13 quoted lines

> Johannes Sixt <j6t@kdbg.org> writes:
>
>> Sigh. DCLP, the Double Checked Locking Pattern. ...
>> I suggest you go without it, then measure, and only *then* optimize if
>> it is a bottleneck.
>
> That comes from me in earlier discussion before the patch, namely in
> <xmqqeg3m8y6y.fsf@gitster.mtv.corp.google.com>, where I wondered if
> a cheap check outside the lock may be a possible optimization
> opportunity, as this is a classic singleton that will not be
> deinitialized, and once the codepath gets exercised, we would be
> taking the "nothing to do" route 100% of the time.
>

Having followed that advice (and internally having a DCLP), I think we have Triple Checked Locking Pattern in this patch. Nobody wrote a paper on how that would not work, yet. ;)

In the reroll I plan to reduce it to a Single Checked (inside a mutex) Locking Pattern, though I would expect that performance (or lack thereof) will show then. But let's postpone measuring until we have a working patch.