From: hboehm Date: Tue, 15 May 2007 18:57:48 +0000 (+0000) Subject: 2007-05-15 Hans Boehm X-Git-Tag: gc7_0alpha9^0 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=6db732a6f429e978e4e02f0cac46b5b677aed7e8;p=libatomic_ops 2007-05-15 Hans Boehm * 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. --- diff --git a/ChangeLog b/ChangeLog index a1f6ba9..5a0f8c7 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,6 @@ +2007-05-14 Hans Boehm + doc/README.txt: Update to reflect C++0x effort. + 2007-05-07 Hans Boehm (with help from Philipp Zambelli) * src/atomic_ops/sysdeps/msftc/x86.h: Don't just assume that mfence is present. diff --git a/doc/README.txt b/doc/README.txt index 2bc59e1..fa8f07e 100644 --- a/doc/README.txt +++ b/doc/README.txt @@ -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: