🚀 go-pugleaf

Proposed: Perprocess Variable Extension to C

The goal of this extension is to provide global
variables that are private to a single thread in
a multi-threaded, shared memory program.

In this discussion, process is synonymous with thread.

This extension assumes multi-threaded, shared memory,
and single address space programs.

In this scheme, global variables in the source code
may have one of the following to mutually exclusive
attributes: "shared" or "perprocess". 

Every thread with a program posesses its own private
copy of the programs set of perprocess variables.
Only one copy of shared variables exist per program.
All threads within a program have equal and unsynchronized
access to these shared variables.

At process creation, child processes inherit the values of
their parent's perprocess variables. During program
initialization, the root thread's perprocess variables
may be intialized with constant values specified in the
program text or left uninitialized just as shared variables
may be.

Global variables are "perprocess" by
default. If global variables are to be shared among
threads, then they are declared "shared". This
ensures that only variables that the programmer 
explicity intends to be shared are shared, eliminating
unintended race conditions and side effects by other
processes.

Caveats:

Note that the address of a perpocess variable is not
a compile time value. Thus, the following program fragment:

int foo;
int *bar = &foo;

Is illegal because the address of foo is dependent on the
current process.

The following code is legal:

shared int foo;
int *bar foo;

since the addresses of shared variables are known at 
compile time.

Note: Spinlock variables should always be shared.

Implementation:

At Stanford's Distributed Systems Group, we have 
implemented perprocess variables for both the
vax and m68k architectures running under the V 
Distributed System. The V systems supports 
multiple threads and shared memory communication 
between them.

A register is reserved to point to a processes perprocess
area. All perprocess variables are references off of this
register. The use of this register is transparent to the 
C programmer.

This implementation is based on the GNU compilation system.
Changes were required in the compiler, assembler, linker, and
related programs. 

The BSD-style GNU object format was extended to support two additional
segments: the initialized and uninitialized 
perprocess segments of the program's root
thread. The V System program loader was modified
to accept the new object format. 

With the increasing popularity of threads, this extension
should become increasingly useful.

Other work:
Apparently, Sequent and Encore systems have similar
support for "private" and "shared" variables. The
difference between this approach and the Sequent one
is that Sequents environment is not a shared memory (threads)
one by default. Instead, address spaces must be explicitly
shared.  In the V System, the operating system kernel itself
is unaware of perprocess versus shared variables, but 
supports threads and shared memory.

I don't know what the GNU OS will be like, but if it
is like Mach, then both of these models can be supported,
but object format changes will have to be made. 

Since the storage models of C and C++ are essentially 
the same. C++ could be similarly extended with 
"shared" and "perprocess" variables.

It would be nice for people with multiple processing
interests in gcc to coordinate their efforts.
I would love to have my stuff integrated into gcc proper.
Currently, my changes are #ifdef in my copy of
the source code. I'd love to get my stuff into gcc proper, but didn't think
that it was applicable. My design and implementation may
not be what you want exactly, but I'm definitely willing
to comprimise to get the general concept into the Gnu
compilation system.

Please comment.

Peter

--
Peter Ham			PO Box 3430	(h)(415) 324-9645
MS Computer Science Student	Stanford, CA	ham@polya.stanford.edu
Stanford University 		94309		(o)(415) 723-2067