This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
[PATCH COMMITTED] malloc: Update comment for list_lock
- From: Florian Weimer <fweimer at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>, Torvald Riegel <triegel at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 23 Dec 2015 17:29:45 +0100
- Subject: [PATCH COMMITTED] malloc: Update comment for list_lock
- Authentication-results: sourceware.org; auth=none
- References: <56389C10 dot 6060001 at redhat dot com> <56642691 dot 7060806 at redhat dot com> <1449852593 dot 27311 dot 98 dot camel at localhost dot localdomain> <566F1114 dot 1060706 at redhat dot com> <1450380373 dot 26597 dot 29 dot camel at localhost dot localdomain> <56740C24 dot 90901 at redhat dot com> <5678751E dot 1030605 at redhat dot com> <5679A559 dot 6010703 at redhat dot com> <5679AF92 dot 9080406 at redhat dot com>
On 12/22/2015 09:16 PM, Carlos O'Donell wrote:
> On 12/22/2015 02:32 PM, Florian Weimer wrote:
>> On 12/21/2015 10:54 PM, Carlos O'Donell wrote:
>>
>>>> + list_lock also prevents concurrent forks. When list_lock is
>>>> + acquired, no arena lock must be acquired, but it is permitted to
>>>> + acquire arena locks after list_lock. */
>>>
>>> This last sentence seems ambiguous to me. I assume you mean to say that
>>> at the point at which list_lock is acquired there are no other arena
>>> locks held, but that after list_lock is acquired, other arena locks may
>>> be acquired afterwards?
>>
>> That was my intent. Is this clearer?
>>
>> list_lock also prevents concurrent forks. At the time list_lock is
>> acquired, no arena lock must have been acquired, but it is permitted
>> to acquire arena locks subsequently, while list_lock is acquired.
>>
>> I'm following Torvald's earlier guidance not to speak of âheldâ locks.
>
> Looks good to me.
Thanks, committed.
Florian
>From 7962541a32eff5597bc4207e781cfac8d1bb0d87 Mon Sep 17 00:00:00 2001
Message-Id: <7962541a32eff5597bc4207e781cfac8d1bb0d87.1450888146.git.fweimer@redhat.com>
From: Florian Weimer <fweimer@redhat.com>
Date: Wed, 23 Dec 2015 17:23:33 +0100
Subject: [PATCH] malloc: Update comment for list_lock
To: libc-alpha@sourceware.org
---
ChangeLog | 4 ++++
malloc/arena.c | 7 ++++---
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index a32717e..9063848 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2015-12-23 Florian Weimer <fweimer@redhat.com>
+
+ * malloc/arena.c (list_lock): Update comment.
+
2015-12-22 Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
* sysdeps/powerpc/hwcapinfo.c: Export symbol
diff --git a/malloc/arena.c b/malloc/arena.c
index 85f1194..665be5e 100644
--- a/malloc/arena.c
+++ b/malloc/arena.c
@@ -85,9 +85,10 @@ static mstate free_list;
_int_new_arena. This suffers from data races; see the FIXME
comments in _int_new_arena and reused_arena.
- list_lock also prevents concurrent forks. When list_lock is
- acquired, no arena lock must be acquired, but it is permitted to
- acquire arena locks after list_lock. */
+ list_lock also prevents concurrent forks. At the time list_lock is
+ acquired, no arena lock must have been acquired, but it is
+ permitted to acquire arena locks subsequently, while list_lock is
+ acquired. */
static mutex_t list_lock = _LIBC_LOCK_INITIALIZER;
/* Mapped memory in non-main arenas (reliable only for NO_THREADS). */
--
2.4.3