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 bonachea@cs.berkeley.edu 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 6.4.3.2

– Freeing all_alloc: Current spec says that all thread call upc_free • Not free until all have called it• But free says that 2nd 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 bonachea@cs.berkeley.edu for LBL spec

•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 1st

•Circulate it by the 15th.•June 1st 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: <io.h> 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 signal3.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