diff mbox

[UPC,18/22] libatomic changes

Message ID 20151201060241.GA31328@intrepid.com
State New
Headers show

Commit Message

Gary Funck Dec. 1, 2015, 6:02 a.m. UTC 
Background
----------

An overview email, describing the UPC-related changes is here:
  https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00005.html

The GUPC branch is described here:
  http://gcc.gnu.org/projects/gupc.html

The UPC-related source code differences are summarized here:
  http://gccupc.org/gupc-changes

All languages (c, c++, fortran, go, lto, objc, obj-c++) have been
bootstrapped; no test suite regressions were introduced,
relative to the GCC trunk.

If you are on the cc-list, your name was chosen either
because you are listed as a maintainer for the area that
applies to the patches described in this email, or you
were a frequent contributor of patches made to files listed
in this email.

In the change log entries included in each patch, the directory
containing the affected files is listed, followed by the files.
When the patches are applied, the change log entries will be
distributed to the appropriate ChangeLog file.

Overview
--------

The UPC language specification defines atomic operations on
UPC shared data, implemented by a set of library routines.

The UPC runtime library, targeting SMP (symmetric multiprocessor) systems,
uses GCC builtin atomic operations to implement atomic operations
on UPC shared values.  GCC's builtin atomic operations use libatomic
to handle various situations where direct hardware support is unavailable.
During testing, we noticed that when some operations or types are
unsupported that the library will call an internal lock routine and
this lock routine calls pthread_mutex().  That doesn't work well for
UPC because by default a UPC "thread" maps to an OS process.
We discussed this issue in this bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60790.

To work around this locking issue, we build a statically linked
"convenience" library, libatomic_convenience_no_lock.a.
This is the same as the libatomic_convenience library built for libgo,
except it doesn't include lock.o.  In libgupc/smp, the source
file upc_libat_lock.c defines the same entry points as lock.c,
but implements them using a spin lock.

2015-11-30  Gary Funck  <gary@intrepid.com>

	libatomic/
	* Makefile.am (LIBAT_SRC_NO_LOCK, libatomic_convenience_no_lock*):
	New.  Add rules to build libatomic_convenience_no_lock.a,
	used by libgupc.
	* Makefile.in: Re-generate.
diff mbox

Patch

Index: libatomic/Makefile.am
===================================================================
--- libatomic/Makefile.am	(.../trunk)	(revision 231059)
+++ libatomic/Makefile.am	(.../branches/gupc)	(revision 231080)
@@ -40,7 +40,8 @@  AM_CCASFLAGS = $(XCFLAGS)
 AM_LDFLAGS = $(XLDFLAGS) $(SECTION_LDFLAGS) $(OPT_LDFLAGS)
 
 toolexeclib_LTLIBRARIES = libatomic.la
-noinst_LTLIBRARIES = libatomic_convenience.la
+noinst_LTLIBRARIES = libatomic_convenience.la \
+                     libatomic_convenience_no_lock.la 
 
 if LIBAT_BUILD_VERSIONED_SHLIB
 if LIBAT_BUILD_VERSIONED_SHLIB_GNU
@@ -67,8 +68,9 @@  endif
 libatomic_version_info = -version-info $(libtool_VERSION)
 
 libatomic_la_LDFLAGS = $(libatomic_version_info) $(libatomic_version_script) $(lt_host_flags)
-libatomic_la_SOURCES = gload.c gstore.c gcas.c gexch.c glfree.c lock.c init.c \
+LIBAT_SRC_NO_LOCK = gload.c gstore.c gcas.c gexch.c glfree.c 0 init.c \
 	fenv.c fence.c flag.c
+libatomic_la_SOURCES = $(LIBAT_SRC_NO_LOCK) lock.c
 
 SIZEOBJS = load store cas exch fadd fsub fand fior fxor fnand tas
 SIZES = @SIZES@
@@ -139,3 +141,9 @@  endif
 
 libatomic_convenience_la_SOURCES = $(libatomic_la_SOURCES)
 libatomic_convenience_la_LIBADD = $(libatomic_la_LIBADD)
+
+# The "no lock" convenience library is used by libgupc to
+# avoid lock.c's use of pthread_mutex, which won't work
+# for processes using atomics on shared memory.
+libatomic_convenience_no_lock_la_SOURCES = $(LIBAT_SRC_NO_LOCK)
+libatomic_convenience_no_lock_la_LIBADD = $(libatomic_la_LIBADD)