Strengthen typechecking on upc_atomic_[strict,relaxed]

Originally reported on Google Code with ID 121
We've been doing alot of recent work with the spec 1.3 optional atomics API, and I have
some design feedback based on recent experience. Overall the API seems powerful, expressive
and flexible to both clients and implementers. 

However, an annoying design weakness of the current API is the lack of useful typechecking
on upc_atomic_{relaxed,strict}. The API makes far too easy to make subtle mistakes
like this:

#include <upc.h>
#include <upc_atomic.h>
#include <stdint.h>

shared int64_t sum = 0;

int main() {
  upc_atomicdomain_t *dom = upc_all_atomicdomain_alloc(UPC_INT64, UPC_ADD, 0);

  int val = 1;
  int fetch;
  upc_atomic_relaxed(dom, &fetch, UPC_ADD, &sum, &val, 0);
}

This simple program contains no cast expressions and passes the typechecker, but nevertheless
contains a serious type error that will corrupt stack and heap memory (in ways that
are system specific and may even go unnoticed on some configurations). The bug is rather
obvious when written like this, but sadly is an easy mistake to make when the declarations
are spread out in a large program. Other variants are possible, whenever any of the
five types (domain_alloc upc_type_t, typeof(*target), typeof(*fetch), typeof(*operand1),
typeof(*operand2)) do not all perfectly match. Worse, the design of the API means the
problem cannot be diagnosed by the library, even at runtime, without some hefty compiler
assistance (although I do think this is an alternative worth investigating).

Atomics are admittedly a tool for "sophisticated" users, but I fear the complete lack
of static type checking on the tool we're handing them implies more pointy edges than
even a veteran UPC programmer should be expected to navigate. Typeless interfaces are
common in C (eg memcpy, upc_memput), but in those cases the user has specifically elected
to use a typeless byte copy API (and the nbytes parameter forces them to think about
bytes at every call). Our atomicdomain alloc call gives the superficial illusion of
presenting a typed interface, but there is no useful type checking at the domain usage
point, and the user has no strongly-typed alternative to accomplish the same task.

Solutions I've considered:
1. Use C++ templates (joking, but would actually help here)
2. Use compiler help to supply actual argument type information to the use library
call for checking at runtime (only helps while using high-quality debug implementations)
3. Clone the upc_atomic_{relaxed,strict} entry points once per upc_type_t to accept
well-typed arguments (and deprecate the current typeless version). This option would
also allow us to take operand1/operand2 by value (a separate design question).
4. Use C11 type-generic functions to do the same thing as #3 without polluting the
function name space (this is how the C11 atomics solve the same problem)
Reported by danbonachea on 2014-04-15 09:47:50
Comments (5)
