]> granicus.if.org Git - libatomic_ops/commitdiff
2007-05-15 Hans Boehm <Hans.Boehm@hp.com> gc7_0alpha9
authorhboehm <hboehm>
Tue, 15 May 2007 18:57:48 +0000 (18:57 +0000)
committerIvan Maidanski <ivmai@mail.ru>
Mon, 25 Jul 2011 12:03:23 +0000 (16:03 +0400)
* Makefile.am: Include NT_STSTIC_THREADS_MAKEFILE in dist.
* Makefile.in: Regenerate.
* include/private/gc_locks.h: GC_compare_and_exchange, GC_atomic_add:
remove. NUMERIC_THREAD_ID, THREAD_EQUAL: New.  GC_lock_holder: now
unsigned long.  I_DONT_HOLD_LOCK, I_HOLD_LOCK: Update.
* pthread_stop_world.c, pthread_support.c, win32_threads.c: Use
NUMERIC_THREAD_ID, THREAD_EQUAL.
* include/private/gcconfig.h: GENERIC_COMPARE_AND_SWAP: Remove.
* include/private/thread_local_alloc.h: Don't USE_COMPILER_TLS on
ARM.
* libatomic_ops-1.2/doc/README.txt: Update to reflect C++
standardization effort.

ChangeLog
doc/README.txt

index a1f6ba9a91ac1330224d2b959a708eae96c5ebb1..5a0f8c7de2f939c82cc1fe78ac48ea05cae950a7 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,6 @@
+2007-05-14 Hans Boehm <Hans.Boehm@hp.com>
+       doc/README.txt: Update to reflect C++0x effort.
+
 2007-05-07  Hans Boehm <Hans.Boehm@hp.com> (with help from Philipp Zambelli)
        * src/atomic_ops/sysdeps/msftc/x86.h: Don't just assume that mfence
        is present.
index 2bc59e1c68dbf81307af70174d401e7e2adaa242..fa8f07edbf5d75440eac065997a4317c57208f28 100644 (file)
@@ -59,8 +59,8 @@ whose size matches that of pointers on the given architecture.  Exceptions
 are:
 
 - AO_test_and_set operates on AO_TS_t, which is whatever size the hardware
-supports with good performance.  In some cases this is the length of a cache line.
-In some cases it is a byte.  In many cases it is equivalent to AO_t.
+supports with good performance.  In some cases this is the length of a cache
+line.  In some cases it is a byte.  In many cases it is equivalent to AO_t.
 
 - A few operations are implemented on smaller or larger size integers.
 Such operations are indicated by the appropriate prefix:
@@ -162,7 +162,8 @@ _dd_acquire_read: Ordered with respect to later reads that are data
               a pointer read, which is later dereferenced to read a
               second value, with the expectation that the second
               read is ordered after the first one.  On most architectures,
-              this is equivalent to no barrier.
+              this is equivalent to no barrier.  (This is very
+              hard to define precisely.  It should probably be avoided.)
 _release_read: Ordered with respect to earlier reads.  Useful for
               implementing read locks.  Can be implemented as _release,
               but not as _read, since _read groups the current operation
@@ -194,10 +195,22 @@ make list_atomic.i
 
 Future directions:
 
-We expect the list of memory barrier types to remain more or less fixed.
-However, it is likely that the list of underlying atomic operations will
-grow.  It would also be useful to support double-wide and narrower operations
-when available.
+It currently appears that something roughly analogous to this is very likely
+to become part of the C++0x standard.  That effort has pointed out a number
+of issues that we expect to address there.  Since some of the solutions
+really require compiler support, they may not be completely addressed here.
+
+Known issues include:
+
+We should be more precise in defining the semantics of the ordering
+constraints, and if and how we can guarantee sequential consistency.
+
+Dd_acquire_read is very hard or impossible to define in a way that cannot
+be invalidated by reasonably standard compiler transformations.
+
+There is probably no good reason to provide operations on standard
+integer types, since those may have the wrong alignment constraints.
+
 
 Example: