Communication API and Language

Communication API Issues –Should there be a common communication API? Generally a good idea –Make network vendors do more work –Compiler writers will be able to leverage Vendors will need incentive to use –Performance vs. Portability MTU and LBL efforts are orthogonal Action item: –Mail to see the LBL draft runtime and communication layer spec

Language Issues Language issues (1 hour) –Locks (Dan) –Pragma for shared (Bill) Richard Stallman’s: pragmas vs. upc_strict Language level “strict” or memory barriers –Thread/process issues Calling libraries from UPC Maintain C spec for thread-local things –Freeing result of all_alloc() –Atomicity (Bill and Kathy…) –Signals: no semantics for externally generated signals (Dan) Proposal: undefined (no requirements imposed) –Poll (Kathy) Proposal: overload fence to have this effect on systems that need it

Poll Can we make progress in the following: shared int *x; shared int *y; *y = 1; *x = 1; while(!*x); while (!*y) This example isn’t quite enough, because x and y have to be strict, so there is a fence in the spin loop Proposal: table this discussion and think of the right way to say this

Specification Issues Quick specification issues –upc_phaseof for pointers with indef. block size (Dan and Jim and Brian) Proposal: return 0 –upc_barrier and barrier Proposal: eliminate the macros from the Spec –Spec: change wording to pointer to shared, not shared pointer Proposal: plan to change, but look at spec –Interaction between UPC max block size and array size Proposal: illegal

More Spec Issues –Thread of a[0] Block sizes on scalars (Sid) shared [3] int x; –Aside: more cleanly written as: int shared [3] x; Proposal: leave it as-is –Does phaseof(&a[0]) return 0 for static array a? Proposal: yes Threadof is also thread 0: implied by Section –Freeing all_alloc: Current spec says that all thread call upc_free Not free until all have called it But free says that 2 nd call to free is undefined Proposal: change wording so that first call frees the

More on shared/blocked Shared [3] int x [100]; &(x[10]) is a pointer to shared [3] int What is the type of x[10] ? –Wrong: shared int –Answer: shared [3] int

Atomicity What is the atomic “type” of the language? –I.e., smallest unit of reads/writes –Sig_atomic_t in C –Should we at upc_atomic_t ? Or a size? Two properties: –Cannot “tear” value and see partially-updated results –Cannot “clobber” values outside of the one accessed (e.g., writing to an array Issue: can this be implemented on all systems? –64-bit system with a 32-bit network card

Threads/Process Summary Two problems : –Linkage issue in pthreads If small number of problems, we may add to spec. –Semantics of library objects How many do you get? Are they shared/local? Principles: –Any C program is a valid UPC program –C libraries should work on a per-thread basis Proposal: Leave spec “as-is” but plan to extend the abstract machine model for C to UPC. –Look at pthread spec., CAF, hope the I/O figure this out… –Start by enumerating problems

Action Items Plan pthread implementations –Mahesha will investigate Extend C’s machine model (Sid to lead) –Standard library semantics (stderr,…) –Atomicity Modifications to spec –Send detailed requests to Tarek for integration (Sid, Dan, …) Relaxed/strict –Gary and Bill – continue talking to “gnu” Runtime: –send mail to for LBL upc-run: didn’t talk about this –Identify a group to generate a draft –Implementors: Compaq, LBNL, Cray, HP, …

Schedule Any requests for changes to Bill by April 1 st Circulate it by the 15 th. June 1 st 1.1 draft will become the spec if no one objects

Threads/Process Issues Calling library (sequential) from UPC code in pthread implementations of UPC –Statically declared global variables in libraries, e.g., stdio defined __iobuff as a global variable Address space conflicts –Proposal: May have a standard solution for pthread implementations Including using the following: may come from a different place in UPC than in C Calling C/F functions from UPC –J.5.9 in C: “Fortran” keyword (p. 508) –Leave this undefined Thread safety –This is a known problem

Threads/Process Issues File example: –Cannot take a file descriptor and pass it to another UPC thread and have it work It may, in some implementations, but won’t May be a different limit on # of files in pthread UPC than C –Does the UPC spec say anything about File descriptors (in particular, 3 standard IO channels like stderr, errno) and whether they are local or shared How many of them are there? Principles: –Any C program is a valid UPC program –C libraries should work on a per-thread basis

Locks Spec currently allows statically allocated locks upc_lock_t L; upc_lock_init(&L); // should not be used Prevent users from assigning locks upc_lock_t L, M; L = M; // should not be used Proposal: –make upc_lock_t an “incomplete” type This is an ANSI C notion (a struct with unknown fields) No statically allocated locks (no sizeof) –init function disappears upc_lock_init() // should disappear –Open issue: should upc_lock_t be a pointer to shared or completely opaque. (Greg and Gary) Default is pointer to shared

More on Locks How to free locks? –Proposal: add to the spec upc_lock_free() What is the consistency model for lock operations –Proposal: specify that lock operations are implicitly null strict references upc_lock  acquire null strict reference upc_unlock  null strict reference release Issue: over-synchronizes (relative to Java) –Because it synchronizes movement in two directions –But we decided to go with it anyway

Recursive Locks What happens if you acquire a lock that is already being held. Proposals: 1.Undefined Implementations may include mechanisms to detect these problems 2.Throw a standard C signal 3.OK, but behaves as if only locked once (unlock will release both) 4.OK and recursive –Issue: allow for future recursive lock extensions –Issue: speed of successfully acquiring a lock Allowing undefined behavior is fastest (single bit implementation of locks) –Conclusion: undefined

Strict/Relaxed Language Support Current scenario: #pragma upc_relaxed can appear at file scope or block beginning Issue: pragmas are bad –Cannot be included in macros (except in C99) Proposal #1: add upc_strict/relaxed “statements” –Add a new compound statement type: upc_strict statement upc_relaxed statement –Conclusion: Very nice, but a change to the language Proposal #2: –Depracate use of pragmas in blocks #pragma upc_relaxed (and strict) at file scope only Use C99 solution for macros Proposal #3: status quo

Relaxed/Strict Language Support More on proposal #1 –Use in function scope void foo () { … upc_strict; // hold in following code … upc_relaxed; // until here …} –Use in file scope – upc_strict; // outside of function, e.g., at top of file

Runtime Breakout Topics –Low level communication API –Language issues (1 hour) –Other (? hours) 2 hours of real meeting time today –Runtime (short discussion) –Languages (incomplete) 1.5 hours tomorrow –Remaining language issues