lib/glibc
1
0
Fork 0
mirror of https://sourceware.org/git/glibc.git synced 2025-07-28 00:21:52 +03:00
Code Activity

Mention dl_load_lock by name in the comments

Browse Source 
Mention dl_load_lock by name instead of just 'load lock' in the
comments.  This makes it unambigious which lock we're talking about.
This commit is contained in:
Siddhesh Poyarekar
2015-07-24 06:09:47 +05:30
parent b301e68e4b
commit a81a00ff94
2 changed files with 15 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
ChangeLog
View File

@ -1,3 +1,8 @@
2015-07-24 Siddhesh Poyarekar <siddhesh@redhat.com>
* stdlib/cxa_thread_atexit_impl.c: Use the lock name dl_load_lock
instead of just saying load lock in the comments.
2015-07-23 Roland McGrath <roland@hack.frob.com> 2015-07-23 Roland McGrath <roland@hack.frob.com>
* sysdeps/unix/Subdirs: Moved ... * sysdeps/unix/Subdirs: Moved ...

19
stdlib/cxa_thread_atexit_impl.c
View File

@ -25,14 +25,15 @@
combinations of all three functions are the link map list, a link map for a combinations of all three functions are the link map list, a link map for a
DSO and the link map member l_tls_dtor_count. DSO and the link map member l_tls_dtor_count.
__cxa_thread_atexit_impl acquires the load_lock before accessing any shared __cxa_thread_atexit_impl acquires the dl_load_lock before accessing any
state and hence multiple of its instances can safely execute concurrently. shared state and hence multiple of its instances can safely execute
concurrently.
_dl_close_worker acquires the load_lock before accessing any shared state as _dl_close_worker acquires the dl_load_lock before accessing any shared state
well and hence can concurrently execute multiple of its own instances as as well and hence can concurrently execute multiple of its own instances as
well as those of __cxa_thread_atexit_impl safely. Not all accesses to well as those of __cxa_thread_atexit_impl safely. Not all accesses to
l_tls_dtor_count are protected by the load lock, so we need to synchronize l_tls_dtor_count are protected by the dl_load_lock, so we need to
using atomics. synchronize using atomics.
__call_tls_dtors accesses the l_tls_dtor_count without taking the lock; it __call_tls_dtors accesses the l_tls_dtor_count without taking the lock; it
decrements the value by one. It does not need the big lock because it does decrements the value by one. It does not need the big lock because it does
@ -51,8 +52,8 @@
it is safe to unload the DSO. Hence, to ensure that this does not happen, it is safe to unload the DSO. Hence, to ensure that this does not happen,
the following conditions must be met: the following conditions must be met:
1. In _dl_close_worker, the l_tls_dtor_count load happens before the DSO 1. In _dl_close_worker, the l_tls_dtor_count load happens before the DSO is
is unload and its link map is freed unloaded and its link map is freed
2. The link map dereference in __call_tls_dtors happens before the 2. The link map dereference in __call_tls_dtors happens before the
l_tls_dtor_count dereference. l_tls_dtor_count dereference.
@ -122,7 +123,7 @@ __cxa_thread_atexit_impl (dtor_func func, void *obj, void *dso_symbol)
/* This increment may only be concurrently observed either by the decrement /* This increment may only be concurrently observed either by the decrement
in __call_tls_dtors since the other l_tls_dtor_count access in in __call_tls_dtors since the other l_tls_dtor_count access in
_dl_close_worker is protected by the load lock. The execution in _dl_close_worker is protected by the dl_load_lock. The execution in
__call_tls_dtors does not really depend on this value beyond the fact that __call_tls_dtors does not really depend on this value beyond the fact that
it should be atomic, so Relaxed MO should be sufficient. */ it should be atomic, so Relaxed MO should be sufficient. */
atomic_fetch_add_relaxed (&lm_cache->l_tls_dtor_count, 1); atomic_fetch_add_relaxed (&lm_cache->l_tls_dtor_count, 1);