Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!usc!cs.utexas.edu!mailrus!cornell!rochester!crowl
From: crowl@cs.rochester.edu (Lawrence Crowl)
Newsgroups: gnu.gcc.bug
Subject: Re: perprocess variable proposal (please comment)
Message-ID: <1989Sep14.155839.20429@cs.rochester.edu>
Date: 14 Sep 89 15:58:39 GMT
References: <HAM.89Sep13105654@Neon.Stanford.EDU>
Reply-To: crowl@cs.rochester.edu.UUCP (Lawrence Crowl)
Distribution: gnu
Organization: U of Rochester, CS Dept, Rochester, NY
Lines: 63

In article <HAM.89Sep13105654@Neon.Stanford.EDU>
ham@Neon.Stanford.EDU (Peter R. Ham) writes:
>
>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". 

C does not have a notion of thread or of process.  To add the concept of a
'perprocess', you must impose a model of 'process'.  You also  assume a rather
specific uniform-memory-access architecture.  I use a non-uniform-memory-access
archtecture in which *where* the data lives is every bit as important as
whether or not it is shared.  I believe it is premature to impose a process
model on C.  Therefore, 'perprocess' variables are too specific and premature.  

>Global variables are "perprocess" by default. If global variables are to be
>shared among threads, then they are declared "shared". ...  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.

This is inconsistent with the current definition of C.  I must be able to run
current single-thread programs without modification.

>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.

We can achieve near this effect through use of the GNU global register variable
facility.  Define all 'perprocess' variables as members of a structure type.
And then set the global register variable to point to the current process's
'perprocess' variables.  For example,

    struct perprocess { ... } ;
    register struct perprocess *my_process asm ( "a5" ) ;

In contrast to the proposed 'perprocess' variables, using a global register
variable:

  - does not require modification of the GNU compilation system
  - does not presume a model of processes
  - does not presume an architecture
  - does require explicit structure access
  - does require explicit structure initialization
         (as opposed to the inheritance proposed)

In summary, the mechanisms are in place to get near the semantics you want,
with a little extra programmer effort.  To do better requires making
assumptions in C about the machine architecture and process model that I
believe are premature for *C*.  So, I believe the 'perprocess' proposal should
not be adopted.

-- 
  Lawrence Crowl		716-275-9499	University of Rochester
		      crowl@cs.rochester.edu	Computer Science Department
...!{allegra,decvax,rutgers}!rochester!crowl	Rochester, New York,  14627