From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Subject: Re: [PATCH v3 3/3] index-pack: support multithreaded delta resolving
Date: Fri, 4 May 2012 19:50:26 +0700 [thread overview]
Message-ID: <CACsJy8DHtBZdhoh1BPwn2_-3wVDRWypJOg3kR9wjd2o1bLUW-Q@mail.gmail.com> (raw)
In-Reply-To: <7vipgccvp9.fsf@alter.siamese.dyndns.org>
Junio, can you make a patch (or update current ones) with better
naming? I obviously did not see why these names were bad. You may
provide more convincing explanation than me in the commit message.
On Fri, May 4, 2012 at 1:21 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>>
>>> @@ -696,7 +796,31 @@ static void second_pass(struct object_entry *obj)
>>> base_obj->obj = obj;
>>> base_obj->data = NULL;
>>> find_unresolved_deltas(base_obj);
>>> - display_progress(progress, nr_resolved_deltas);
>>> +}
>>> +
>>> +static void *threaded_second_pass(void *arg)
>>> +{
>>> +#ifndef NO_PTHREADS
>>> + if (threads_active)
>>> + pthread_setspecific(key, arg);
>>> +#endif
>>> + for (;;) {
>>> + int i;
>>> + work_lock();
>>> + display_progress(progress, nr_resolved_deltas);
>>> + while (nr_processed < nr_objects &&
>>> + is_delta_type(objects[nr_processed].type))
>>> + nr_processed++;
>>> + if (nr_processed >= nr_objects) {
>>> + work_unlock();
>>> + break;
>>> + }
>>> + i = nr_processed++;
>>> + work_unlock();
>>> +
>>> + second_pass(&objects[i]);
>>> + }
>>> + return NULL;
>>> }
>>
>> It may be just the matter of naming, but the above is taking the
>> abstraction backwards, I think. Shouldn't it be structured in such a way
>> that the caller may call second_pass() and its implementation may turn out
>> to be threaded (or not)?
>>
>> The naming of "arg" made things worse. I wasted 5 minutes scratching my
>> head thinking "arg" was a single specific object that was to be given to
>> second_pass(), and wondered why it is made into thread-local data. Name
>> it "thread_data" or something.
>>
>> And I think the root cause of this confusion is the way "second_pass" was
>> split out in the earlier patch. It is not the entire second-pass, but is
>> merely a single step of it (the whole "for (i = 0; i < nr_objects; i++)"
>> is the second-pass, in other words), and its implementation detail might
>> change to either thread (i.e. instead of a single line of control
>> iterating from 0 to nr_objects, each thread grab the next available task
>> and work on it until everything is exhausted) or not.
>>
>> By the way, if one object is very heavy and takes a lot of time until
>> completion, could it be possible that objects[0] is still being processed
>> for its base data but objects[1] has already completed and an available
>> thread could work on objects[2]? How does it learn to process objects[2]
>> in such a case, or does it wait until the thread working on objects[0] is
>> done?
>
> Please disregard the "By the way" part, except that my confusion that led
> to the "By the way" comment was caused by another misnaming, namely,
> "nr_processed". It is not counting "How many of them have we already
> processed?"---it merely counts "How many of them have we dispatched?" and
> completion of the task does not matter in this critical section, which I
> missed. If it were named "nr_dispatched", I wouldn't have wasted my time
> wondering about the loop and writing the "By the way" review comment.
>
--
Duy
next prev parent reply other threads:[~2012-05-04 12:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-11 5:49 [PATCH v3 0/3] Multithread index-pack Nguyễn Thái Ngọc Duy
2012-04-11 5:49 ` [PATCH v3 1/3] compat/win32/pthread.h: Add an pthread_key_delete() implementation Nguyễn Thái Ngọc Duy
2012-04-11 5:49 ` [PATCH v3 2/3] index-pack: split second pass obj handling into own function Nguyễn Thái Ngọc Duy
2012-04-11 5:49 ` [PATCH v3 3/3] index-pack: support multithreaded delta resolving Nguyễn Thái Ngọc Duy
2012-05-03 22:10 ` Junio C Hamano
2012-05-04 6:21 ` Junio C Hamano
2012-05-04 12:50 ` Nguyen Thai Ngoc Duy [this message]
2012-05-04 15:23 ` Junio C Hamano
2012-05-06 12:31 ` [PATCH 1/4] compat/win32/pthread.h: Add an pthread_key_delete() implementation Nguyễn Thái Ngọc Duy
2012-05-06 12:31 ` [PATCH 2/4] index-pack: restructure pack processing into three main functions Nguyễn Thái Ngọc Duy
2012-05-08 0:19 ` Junio C Hamano
2012-05-06 12:31 ` [PATCH 3/4] index-pack: support multithreaded delta resolving Nguyễn Thái Ngọc Duy
2012-05-06 12:31 ` [PATCH 4/4] index-pack: disable threading if NO_PREAD is defined Nguyễn Thái Ngọc Duy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACsJy8DHtBZdhoh1BPwn2_-3wVDRWypJOg3kR9wjd2o1bLUW-Q@mail.gmail.com \
--to=pclouds@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=ramsay@ramsay1.demon.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).