Strengthen typechecking on upc_atomic_[strict,relaxed]
Issue #121
new
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)
-
Account Deleted -
Account Deleted Given that C11 supports atomics, I fail to see why that interface shouldn't be used. If you end up doing #3, how is UPC any better than SHMEM? Isn't the point of doing a language instead of a library to _not_ have an entry point per type?
Reported by
jeff.science
on 2014-12-13 06:19:11 -
Account Deleted There was a previous discussion thread regarding C11 atomics, beginning roughly here: https://code.google.com/p/upc-specification/issues/detail?id=7#c52
Reported by
gary.funck
on 2014-12-14 04:23:18 -
Account Deleted Also Dan filed a related issue, suggesting that C11 be considered as the new basis for UPC (rather than C99): https://code.google.com/p/upc-specification/issues/detail?id=86
Reported by
gary.funck
on 2014-12-14 04:29:36 -
Account Deleted Thanks Gary. I should have remembered that. Anyways, I made the comment without try to imagine the implementation details. I just think that UPC has failed if it contains even more semantic bloat than SHMEM, and #3 will do that.
Reported by
jeff.science
on 2014-12-14 04:30:07 - Log in to comment
Reported by
jeff.science
on 2014-12-13 06:15:11