This is the mail archive of the
mailing list for the GCC project.
Make generic atomicity.h use gthr.h mutexes
- From: Phil Edwards <phil at jaj dot com>
- To: libstdc++ at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Thu, 7 Nov 2002 01:43:02 -0500
- Subject: Make generic atomicity.h use gthr.h mutexes
- References: <20021104235307.A25914@disaster.jaj.com> <200211050500.gA550nlo038470@latour.rsch.comm.mot.com> <20021105001156.A26215@disaster.jaj.com>
On Tue, Nov 05, 2002 at 12:11:56AM -0500, Phil Edwards wrote:
> On Mon, Nov 04, 2002 at 11:00:49PM -0600, Loren James Rittle wrote:
> > >I was/am expecting that generic/atomicity.h would be fixed to use gthr.h's
> > >mutexes before 3.2.1 is shipped...
> > As long as the patch to fix i386 isn't moved to release branch before
> > generic/atomicity.h is updated to make correct rather than fast,
> Fixing generic/atomicity.h is something that I should have done some time
> ago. Mea dorkus culpa, where does the time go.
> I've been making good progress on the other projects that I have to do,
> maybe I'll reward myself with some v3 coding this week. (Something that
> doesn't use MILSPECs! Yay!)
Done, patch below. Richard Earnshaw provided a patch
that was simpler than what I had done, so I took his code and made some
Tested by doing a normal build on an SMP Athlon, then replacing the default
atomicity.h with this one, recompiling and rerunning the testsuite.
No additional regressions.
Also tried to test by building a cross compiler targeting i386-pc-linux-gnu
and running it on an SMP Athlon. Failed to build libgcc with
In file included from tconfig.h:23,
/home/pme/src/unified/gcc/config/i386/linux.h:238:20: signal.h: No such file or directory
/home/pme/src/unified/gcc/config/i386/linux.h:239:26: sys/ucontext.h: No such file or directory
gmake: *** [libgcc/./_muldi3.o] Error 1
I don't actually have an i386 to test this on. (My previous computer,
years ago, was an 8086. I'm not joking.)
This is the only atomicity.h which needs to declare a variable at all.
I believe the best place for such things is in the __gnu_cxx namespace,
rather than at the global level. Any reasons not to do so?
I don't believe there are any PRs directly associated with
2002-11-07 Phil Edwards <firstname.lastname@example.org>
Richard Earnshaw <email@example.com>
* atomicity.h: Provide atomic __exchange_and_add and __atomic_add.
RCS file: /home/pme/Repositories/GCC/gcc/libstdc++-v3/config/cpu/generic/atomicity.h,v
retrieving revision 1.3
diff -u -3 -p -r1.3 atomicity.h
--- atomicity.h 24 Jun 2002 05:47:28 -0000 1.3
+++ atomicity.h 7 Nov 2002 06:36:39 -0000
@@ -1,6 +1,6 @@
// Low-level functions for atomic operations: Generic version -*- C++ -*-
-// Copyright (C) 1999, 2001 Free Software Foundation, Inc.
+// Copyright (C) 1999, 2001, 2002 Free Software Foundation, Inc.
// This file is part of the GNU ISO C++ Library. This library is free
// software; you can redistribute it and/or modify it under the
@@ -30,22 +30,37 @@
#define _BITS_ATOMICITY_H 1
typedef int _Atomic_word;
+ __gthread_mutex_t _Atomic_add_mutex __attribute__ ((__weak__))
+ = __GTHREAD_MUTEX_INIT;
static inline _Atomic_word
-__exchange_and_add (_Atomic_word* __mem, int __val)
+__exchange_and_add (volatile _Atomic_word* __mem, int __val)
- _Atomic_word __result = *__mem;
- *__mem += __val;
+ _Atomic_word __result;
+ __gthread_mutex_lock (&__gnu_cxx::_Atomic_add_mutex);
+ __result = *__mem;
+ *__mem += __val;
+ __gthread_mutex_unlock (&__gnu_cxx::_Atomic_add_mutex);
static inline void
-__atomic_add (_Atomic_word* __mem, int __val)
+__atomic_add (volatile _Atomic_word* __mem, int __val)
- *__mem += __val;
+ (void) __exchange_and_add (__mem, __val);
#endif /* atomicity.h */