From: Thomas Rast Date: Tue, 19 Mar 2013 14:16:41 GMT Subject: [PATCH v2] index-pack: guard nr_resolved_deltas reads by lock Message-ID: <8ddf4db38f33034b5ebf504a18948bccf841ab72.1363702423.git.trast@student.ethz.ch> In-Reply-To: The threaded parts of index-pack increment the number of resolved deltas in nr_resolved_deltas guarded by counter_mutex. However, the per-thread outer loop accessed nr_resolved_deltas without any locks. This is not wrong as such, since it doesn't matter all that much whether we get an outdated value. However, unless someone proves that this one lock makes all the performance difference, it would be much cleaner to guard _all_ accesses to the variable with the lock. The only such use is display_progress() in the threaded section (all others are in the conclude_pack() callchain outside the threaded part). To make it obvious that it cannot deadlock, move it out of work_mutex. Signed-off-by: Thomas Rast --- > The only thing I don't > like here is the double locking (work_lock then counter_lock) is an > invitation for potential deadlocks (not now, but who now what can > change later). I think you could move work_lock(); down after > counter_unlock() so we hold one lock at a time. Good point. builtin/index-pack.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/builtin/index-pack.c b/builtin/index-pack.c index b3fee45..a481f54 100644 --- a/builtin/index-pack.c +++ b/builtin/index-pack.c @@ -967,8 +967,10 @@ static void *threaded_second_pass(void *data) set_thread_data(data); for (;;) { int i; - work_lock(); + counter_lock(); display_progress(progress, nr_resolved_deltas); + counter_unlock(); + work_lock(); while (nr_dispatched < nr_objects && is_delta_type(objects[nr_dispatched].type)) nr_dispatched++; -- 1.8.2.490.gc3bbe62