]> git.ipfire.org Git - thirdparty/git.git/commit
grep: replace grep_read_mutex by internal obj read lock
authorMatheus Tavares <matheus.bernardino@usp.br>
Thu, 16 Jan 2020 02:39:54 +0000 (23:39 -0300)
committerJunio C Hamano <gitster@pobox.com>
Fri, 17 Jan 2020 21:52:14 +0000 (13:52 -0800)
commit1d1729caebd41b340dd8dd61057f613da4df526c
treece20d1ca66674bbca7ce8165172598a06a28d0ce
parent31877c9aec21e0824fd4fcf415069cf8dfae4b72
grep: replace grep_read_mutex by internal obj read lock

git-grep uses 'grep_read_mutex' to protect its calls to object reading
operations. But these have their own internal lock now, which ensures a
better performance (allowing parallel access to more regions). So, let's
remove the former and, instead, activate the latter with
enable_obj_read_lock().

Sections that are currently protected by 'grep_read_mutex' but are not
internally protected by the object reading lock should be surrounded by
obj_read_lock() and obj_read_unlock(). These guarantee mutual exclusion
with object reading operations, keeping the current behavior and
avoiding race conditions. Namely, these places are:

  In grep.c:

  - fill_textconv() at fill_textconv_grep().
  - userdiff_get_textconv() at grep_source_1().

  In builtin/grep.c:

  - parse_object_or_die() and the submodule functions at
    grep_submodule().
  - deref_tag() and gitmodules_config_oid() at grep_objects().

If these functions become thread-safe, in the future, we might remove
the locking and probably get some speedup.

Note that some of the submodule functions will already be thread-safe
(or close to being thread-safe) with the internal object reading lock.
However, as some of them will require additional modifications to be
removed from the critical section, this will be done in its own patch.

Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/grep.c
grep.c
grep.h