X3J16/94-0086, WG21/N0473

1


Doc No:	X3J16/94-0086 WG21/N0473
Date:	27 May 94
Project:	Programming Language C++
Reply to:	Michael J. Vilot
ObjectCraft, Inc.
7 Colby Ct., suite #4P321
Bedford NH USA 03110P6427
mjv@objects.mv.com

Reentrancy in the Standard Library

This proposal is for a statement about reentrancy requirements in the Standard C++ library.  The goal is 
to make it possible to implement the library in multithreaded environments, even though this Standard 
does not specify the semantics of C++ in such environments.

2.	Proposal

There are two alternatives to consider.  Only one should be adopted, and added to $17.1, Introduction 
(_lib.introduction_).

Alternative 1:

All functions in the Standard C++ Library shall be reentrant subroutines 1

Alternative 2:

Which of the functions in the Standard C++ Library are not reentrant subroutines is implementation-
defined.

3.	Discussion

The first alternative is the stronger statement, requiring a multithread-safe (MT-safe) Standard C++ 
library.  The main negative impact would be upon implementations seeking to re-use their existing non-
rentrant C libraries, causing them to reimplement them for C++.

This may be unrealistic, and unfortunately also covers parts that are hard to make reentrant (and even to 
specify what reentrant means), such as iostreams.

The second alternative requires implementations to document which of their functions are not MT-safe.  
Unfortunately, this gives few guarantees to portable C++ programs.  However, since we are not 
specifying mutithreading semantics in this Standard, it might be the minimum statement we should 
make.

1The term reentrant subroutine is defined in ANSI X3/TRP1P82:1982 ($1.2, Normative references _intro.refs_).