Johannes Sixt [off-list ref] 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
[off-list ref], 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.
On Wed, Oct 12, 2016 at 2:38 PM, Junio C Hamano [off-list ref] wrote:
Johannes Sixt [off-list ref] writes:
quoted
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
[off-list ref], 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.