In article <1993Nov2.140233.11263@rcmcon.com> rmartin@rcmcon.com (Robert Martin) writes:
>This is written for those observers who want to know what reentrancy is.

>static int i;
>void Increment()
>{
>  int a = i;  // 1
>  a++;        // 2
>  i = a;      // 3
>}

>Those of us who use threads want our compilers to generate code which
>is "thread-safe" (i.e. reentrant).  We also want the standard
>libraries, or at least some reasonable subset of them, to be
>thread-safe.

Do you mean that you want your compiler to translate the above non-
reentrant code into reentrant code?  How is it supposed to do this?
_Why_ should it do this?  In general, any code which has shared
simultaneous access to variables (which is really nothing to do with
reentrancy - it could equally well be two procedures

  static int i
  void funx (void) { i += 2; }
  void funy (void) { i -= 3; }

which get executed simultaneously) requires hardware support, and
special instructions by the programmer, because it is expensive and
because the compiler can't deduce what you want.  (After all, you
might want Increment() to behave exactly the way it's written.)
To achieve reentrancy one would write

  void
  Increment (void) {
    int a = i;
    while (!_compare_and_swap(&i,a+1,&a)) ;
  }
and then one could define
  _atomic_increment_integer(&i);
  _atomic_setbit(&i,0x01);

A much weaker definition of reentrancy than having the C compiler use
atomic instructions on static data is simply the ability to have
private static data for each thread.

ag129@ucs.cam.ac.uk (Alasdair Grant) writes:

>In article <1993Nov2.140233.11263@rcmcon.com> rmartin@rcmcon.com (Robert Martin) writes:
>>This is written for those observers who want to know what reentrancy is.

>>static int i;
>>void Increment()
>>{
>>  int a = i;  // 1
>>  a++;        // 2
>>  i = a;      // 3
>>}

>>Those of us who use threads want our compilers to generate code which
>>is "thread-safe" (i.e. reentrant).  We also want the standard
>>libraries, or at least some reasonable subset of them, to be
>>thread-safe.

>Do you mean that you want your compiler to translate the above non-
>reentrant code into reentrant code?

No, not at all.  I just don't want the compiler to generate non-reentant
code (i.e. use unprotected globals and static variables) while
evaluating expressions.


--
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++

schouten@sp95.csrd.uiuc.edu (Dale Schouten) writes:

>Sorry to butt in, but I'm a little confused by what exactly we mean
>by `re-entrant' in this context, and what features of C++ fail to
>ensure re-entrancy.

This is written for those observers who want to know what reentrancy is.

Consider the following function:

static int i;
void Increment()
{
  int a = i;  // 1
  a++;        // 2
  i = a;      // 3
}

Certainly this function is silly, but bear with me.   The silliness is
a vehicle for the explanation.

This code is not reentrant.  The reason is that it cannot be safely
re-entered.  Why?  Consider a system in which there are several
threads of control, and in which each thread shares the same data
space.  Say there are two threads A and B, both of which call the
Increment function.  It is important to understand that both of these
threads are running in the same data space, so that the 'i' variable
is the same for both of them.

Now let us say that i is 5.  Thread A is currently executing at line 1
of the Increment function.  Suddenly there is an interrupt at the
operating system level and thread A is suspended before it gets to
line 2.  The operating system starts up thread B which calls
Increment.  Increment is now going to be re-entered by B prior to a
proper exit by A.  The B thread will execute line 1 seeing the 5 in i.
It will increment that to a 6 in line 2 and store the 6 back in i in
line 3.

Later, another interrupt will occur.  The operating system will
suspend thread B and thread A will be allowed to continue.  However
thread A had already read the 5 out of i in line 1.  So it will begin
in line 2 by incrementing the 5 to a 6 and then storing the 6 back
into i in line 3.

Now, i started at 5.  Two calls to Increment occurred, but i is now 6.
The entire operation of thread B upon i was lost.

----------------------------------------------------------------------

Threads have been around for a long time, and have been giving
headaches to compiler writers since the 70s.  However the issues are
heating up now more than ever because threads are becoming more
popular than ever.

Those of us who use threads want our compilers to generate code which
is "thread-safe" (i.e. reentrant).  We also want the standard
libraries, or at least some reasonable subset of them, to be
thread-safe.

--
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++

In <1993Nov2.140233.11263@rcmcon.com> rmartin@rcmcon.com (Robert Martin) writes:

>schouten@sp95.csrd.uiuc.edu (Dale Schouten) writes:
>
[ detailed explanation about reentrancy deleted ]
>
>Threads have been around for a long time, and have been giving
>headaches to compiler writers since the 70s.  However the issues are
>heating up now more than ever because threads are becoming more
>popular than ever.
>
>Those of us who use threads want our compilers to generate code which
>is "thread-safe" (i.e. reentrant).  We also want the standard
>libraries, or at least some reasonable subset of them, to be
>thread-safe.
>
Even on systems which do not support threads explicitly the reentrancy
problem exists because signal handlers exist everywhere (or at least on
any ANSI conformant implementation).

Dan
--
Dan Pop
CERN, L3 Experiment
Email: danpop@cernapo.cern.ch
Mail:  CERN - PPE, Bat. 21 1-023, CH-1211 Geneve 23, Switzerland