about summary refs log tree commit diff
path: root/src/locale
diff options
context:
space:
mode:
authorRich Felker <dalias@aerifal.cx>2015-03-03 22:50:02 -0500
committerRich Felker <dalias@aerifal.cx>2015-03-03 22:50:02 -0500
commit56fbaa3bbe73f12af2bfbbcf2adb196e6f9fe264 (patch)
tree09fbe371b108e25bb2f9c90e74da356359950d29 /src/locale
parenteb4bd8d8bb5c9f535ee8250edd4efbd3d4f84c5a (diff)
downloadmusl-56fbaa3bbe73f12af2bfbbcf2adb196e6f9fe264.tar.gz
musl-56fbaa3bbe73f12af2bfbbcf2adb196e6f9fe264.tar.xz
musl-56fbaa3bbe73f12af2bfbbcf2adb196e6f9fe264.zip
make all objects used with atomic operations volatile
the memory model we use internally for atomics permits plain loads of
values which may be subject to concurrent modification without
requiring that a special load function be used. since a compiler is
free to make transformations that alter the number of loads or the way
in which loads are performed, the compiler is theoretically free to
break this usage. the most obvious concern is with atomic cas
constructs: something of the form tmp=*p;a_cas(p,tmp,f(tmp)); could be
transformed to a_cas(p,*p,f(*p)); where the latter is intended to show
multiple loads of *p whose resulting values might fail to be equal;
this would break the atomicity of the whole operation. but even more
fundamental breakage is possible.

with the changes being made now, objects that may be modified by
atomics are modeled as volatile, and the atomic operations performed
on them by other threads are modeled as asynchronous stores by
hardware which happens to be acting on the request of another thread.
such modeling of course does not itself address memory synchronization
between cores/cpus, but that aspect was already handled. this all
seems less than ideal, but it's the best we can do without mandating a
C11 compiler and using the C11 model for atomics.

in the case of pthread_once_t, the ABI type of the underlying object
is not volatile-qualified. so we are assuming that accessing the
object through a volatile-qualified lvalue via casts yields volatile
access semantics. the language of the C standard is somewhat unclear
on this matter, but this is an assumption the linux kernel also makes,
and seems to be the correct interpretation of the standard.
Diffstat (limited to 'src/locale')
-rw-r--r--src/locale/__setlocalecat.c2
-rw-r--r--src/locale/dcngettext.c8
2 files changed, 5 insertions, 5 deletions
diff --git a/src/locale/__setlocalecat.c b/src/locale/__setlocalecat.c
index 1c894d9c..c93e9ba0 100644
--- a/src/locale/__setlocalecat.c
+++ b/src/locale/__setlocalecat.c
@@ -17,7 +17,7 @@ char *__strchrnul(const char *, int);
 
 static struct __locale_map *findlocale(const char *name, size_t n)
 {
-	static void *loc_head;
+	static void *volatile loc_head;
 	struct __locale_map *p, *new, *old_head;
 	const char *path = 0, *z;
 	char buf[256];
diff --git a/src/locale/dcngettext.c b/src/locale/dcngettext.c
index d3462fd2..0057cb56 100644
--- a/src/locale/dcngettext.c
+++ b/src/locale/dcngettext.c
@@ -12,7 +12,7 @@
 struct binding {
 	struct binding *next;
 	int dirlen;
-	int active;
+	volatile int active;
 	char *domainname;
 	char *dirname;
 	char buf[];
@@ -34,7 +34,7 @@ static char *gettextdir(const char *domainname, size_t *dirlen)
 
 char *bindtextdomain(const char *domainname, const char *dirname)
 {
-	static int lock[2];
+	static volatile int lock[2];
 	struct binding *p, *q;
 
 	if (!domainname) return 0;
@@ -96,8 +96,8 @@ struct msgcat {
 	struct msgcat *next;
 	const void *map;
 	size_t map_size;
-	void *plural_rule;
-	int nplurals;
+	void *volatile plural_rule;
+	volatile int nplurals;
 	char name[];
 };