Re: [RFC PATCH 2/3] run-commands: add an async queue processor

[Stefan Beller <sbeller@google.com>]

On Fri, Aug 21, 2015 at 1:47 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> I do not think we are on the same wavelength.  What I meant was to
> do this:
>
>         aq = xmalloc(...);
>         set up _everything_ in aq and make it a consistent state;
>         /* aq->first and aq->last are part of _everything_ in aq */
>         for (many times)
>                 pthread_create(...);
>
>         /* No aq->first = aq->last = NULL assignment here */
>
> instead of
>
>         aq = xmalloc(...);
>         set up part of aq;
>         for (many times)
>                 pthread_create(...);
>         belatedly initialize aq->first and aq->last and finally
>         aq becomes a consistent state.
>
> which is what we see above.  The latter works _only_ because the
> threads created are blocked waiting on aq->workingcount which is
> initialized to block before threads are created to run dispatch,
> and one of the early things dispatch does is to try acquiring that
> semaphore to block before accessing aq->first and aq->last.

I see your point and it makes sense to me as it makes the
mental memory model cleaner

I viewed the methods as atomic units (you would not call add_task
before the constructor has finished, so no harm there. And a dispatcher
in the pthread would just block on the `workingcount` semaphore as the
semaphores are the main inter thread communication. I viewed the queue
as just a secondary thing to distribute the work load.