[Top] [All Lists]

Re: [PATCH v2 4/8] xfsdump: simplify qlock ordinal bitmap

To: Bill Kendall <wkendall@xxxxxxx>
Subject: Re: [PATCH v2 4/8] xfsdump: simplify qlock ordinal bitmap
From: Alex Elder <aelder@xxxxxxx>
Date: Mon, 7 Nov 2011 20:02:16 -0600
Cc: <xfs@xxxxxxxxxxx>
In-reply-to: <1320699511-12281-5-git-send-email-wkendall@xxxxxxx>
References: <1320699511-12281-1-git-send-email-wkendall@xxxxxxx> <1320699511-12281-5-git-send-email-wkendall@xxxxxxx>
Reply-to: <aelder@xxxxxxx>
On Mon, 2011-11-07 at 14:58 -0600, Bill Kendall wrote:
> The qlock abstraction manages an array of ordinal bitmaps, one bitmap
> for each thread. The bitmap indicates which locks a thread is holding
> and is used to verify that the locks are obtained in the correct order.
> There is no need to use an array to store the bitmaps, and in fact
> adding entries to the array is broken because qlock_thrdcnt is not
> protected by a lock. A simpler approach is to create a per-thread bitmap
> using thread local storage.
> With this change, there is no need for each new thread to register with
> the qlock abstraction, so qlock_thrdinit() goes away. Remove
> qlock_init() since it can be statically initialized, and that means
> there's no need for a flag (qlock_inited) indicating that the module has
> been initialized.  Also there's no longer a need to track or limit the
> number of threads that the qlock abstraction can handle.
> Signed-off-by: Bill Kendall <wkendall@xxxxxxx>
> Reviewed-by: Christoph Hellwig <hch@xxxxxx>

Wow, nice cleanup.

Reviewed-by: Alex Elder <aelder@xxxxxxx>

<Prev in Thread] Current Thread [Next in Thread>