Re: [PATCH 28/28] attr: convert to new threadsafe API

[Junio C Hamano <gitster@pobox.com>]

Stefan Beller <sbeller@google.com> writes:

>> You can have many different callsites (think: hits "git grep" finds)
>> that call git_attr_check_initl() and they all may be asking for
>> different set of attributes.  As long as they are using different
>> "check" instance to receive these sets of attributes, they are OK.
>
> Right, but that requires a mutex per callsite; up to now I imagined
> a global mutex only, which is how I came to the conclusion.

Hmph, why?  I agree it would make it easier to allow a mutex keyed
by the address of "check" to enhance parallelism, but I do not think
it _requires_ it, in the sense that if you were anticipating low
contention, one mutex to cover any and all callers to initl() would
still give you a correct result.

I wonder if we can assume and rely on atomicity of store, e.g. if we
can cheaply notice "ah this check is already initialized" without
locking.  Then initl() might become something like

    initl(char **variable, ...)
    {
	struct git_attr_check *check;

    	if (*variable)
            return; /* somebody else did it already */
        acquire lock;
        if (*variable) {
	    /* somebody else was about to finish when we checked earlier */
	    release lock;
	    return;
        }
	check = alloc();
	populate check;
	*variable = check;
	release lock;
    }

and once the system starts running and starts asking the same
question for thousands of paths, the majority of initl() calls
can still be almost no-op, like the original single-threaded

	static struct git_attr_check *check = NULL;
        if (!check)
		check = init();

can avoid heavyweight init() most of the time.