This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 3/5] Add single-threaded path to _int_free
- From: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, nd <nd at arm dot com>
- Date: Thu, 12 Oct 2017 22:21:42 +0000
- Subject: Re: [PATCH 3/5] Add single-threaded path to _int_free
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Wilco dot Dijkstra at arm dot com;
- Nodisclaimer: True
- References: <DB6PR0801MB20534AC3908A760CBE1EA173834B0@DB6PR0801MB2053.eurprd08.prod.outlook.com> (message from Wilco Dijkstra on Thu, 12 Oct 2017 09:35:34 +0000),<xnefq86rf0.fsf@greed.delorie.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
DJ Delorie wrote:
> + /* Check that the top of the bin is not the record we are going to
> + add (i.e., double free). */
> + if (__builtin_expect (old == p, 0))
> + malloc_printerr ("double free or corruption (fasttop)");
> By moving this out of the multi-thread loop, you're removing a check
> against some of the top chunks in the case where the loop happens more
> than once.
Sure, my goal was to share the checks between single and multi-threaded
cases and also keep the loop as simple as possible to reduce the chance
of contention.
How often do we iterate more than once? And what are the chances
that when there is contention, the block at the top of the bin is the same as
the one we're trying to insert but the older one we checked isn't?
If we want to detect double free in almost all cases, wouldn't it be much easier
to check the in-use bit? I can't make much sense of the check on the next chunk
either - that's only done if have_lock == true, so rarely executed.
> + if (SINGLE_THREAD_P)
> {
> If you set have_lock to zero here, you can omit the last two chunks of
> this patch.
To true you mean - yes I can do that.
Wilco