How EGCS with multi-threaded compliance?

How EGCS with multi-threaded compliance?

[Dirk Broer]

I'm searching for a C++ compiler that is multi-thread compliance.

Under a high context switch environment g++ consistently fails.   I've
been told this is to be expected with g++ (even release 2.8x)

Is EGCS better?  Especially the c++ parts?

The word "thread" never showed up in the faq so I fear the worse.

Dirk

Re: How EGCS with multi-threaded compliance?

[Jeffrey A Law]

  In message < 004501bd5f56$50b61ba0$2c91b780@pitcheri.gsfc.nasa.gov >you write:
  > I'm searching for a C++ compiler that is multi-thread compliance.
  > 
  > Under a high context switch environment g++ consistently fails.   I've
  > been told this is to be expected with g++ (even release 2.8x)
  > 
  > Is EGCS better?  Especially the c++ parts?
  > 
  > The word "thread" never showed up in the faq so I fear the worse.
The compiler should produce multi-thread safe code when presented with
multi-thread safe input files.

I do not believe the C++ runtime libraries are multi-thread safe yet,
but I'm sure someone with more knowledge will chime in :-)

jeff

Re: How EGCS with multi-threaded compliance?

[H.J. Lu]

> 
> I do not believe the C++ runtime libraries are multi-thread safe yet,
> but I'm sure someone with more knowledge will chime in :-)
> 

libstdc++ is thread-safe, at least for glibc 2 when it is configured
with --enable-threads. I think it is true for Solaris also, maybe 
for others.

-- 
H.J. Lu (hjl@gnu.org)

Re: How EGCS with multi-threaded compliance?

[David Lucas]

Just a chance to clear up some confusion that I left behind.  I did not
mean to say initialization as in memory to zero, but initialization as
in class object contructors, is not guarenteed through out a library. 
Only the translation unit is guarenteed.  This can get very tricky when
using templates and static space functions invoking static space
objects, etc.  This was all I meant to suggest, not that memory would
not be zero filled.  There is a big difference between memory
initialization and object initialization.

Sorry I was not more clear.

Later,
Dave

-- 
-----------------------------------------------------------------
David Lucas                    |  mailto:dlucas@checkfree.com
Staff Software Engineer        |                                  
Systems Software Development   |  My opinions are IMHO.
OFX Server Devl 08-126         |                                  
                               |
CheckFree Corporation          |  Work#  614.825.3511            
8275 High Street               |  Fax#   614.825.3104            
Columbus, OH 43235             |  http://www.checkfree.com
-----------------------------------------------------------------

Re: How EGCS with multi-threaded compliance?

[Mike Stump]

> Date: Wed, 15 Apr 1998 12:36:17 -0400
> From: David Lucas <dlucas@checkfree.com>

> Alexandre Oliva wrote:
> >Nope, because zero-initialization takes place before any dynamic
> >initialization.

> First off, I prefer Unix over any other OS.  Secondly, my comments
> earlier where in general, compilers do not implement the same nor
> guarentee order of initialization.

General statements aren't very useful, in general.  (:-))

There are hard guarantees abort init order in C++, not many of them,
but there are some.

> Thirdly, where in the C++ specs do you read that zero-initialization
> takes place on anything other than simple types?

  3.6.2  Initialization of non-local objects          [basic.start.init]

1 The storage for objects with static storage duration (3.7.1) shall  be
  zero-initialized  (8.5)  before  any other initialization takes place.

5 To  zero-initialize storage for an object of type  T means:

  - if  T is a non-union class type, the storage for each nonstatic data
    member and each base-class subobject is zero-initialized;

  - if  T is a union type, the storage for its first data  member85)  is
    zero-initialized;

  - if  T is an array type,  the  storage  for  each  element  is  zero-
    initialized;

  - if  T is a reference type, no initialization is performed.


As you can see, pretty clearly states that non-simple types are in
fact zero-initialized.

Re: How EGCS with multi-threaded compliance?

[David Lucas]

Alexandre Oliva wrote:
>Nope, because zero-initialization takes place before any dynamic
>initialization.

Ulrich Drepper wrote:
> 
> No, the bss section is initialized to zeroes even before the
> application (or the DL, resp) gets control.  You must have very little
> confidence in the competence of the people developing Unix systems.
> 

First off, I prefer Unix over any other OS.  Secondly, my comments
earlier where in general, compilers do not implement the same nor
guarentee order of initialization.  Thirdly, where in the C++ specs do
you read that zero-initialization takes place on anything other than
simple types?  

I have not tested egcs to know how it works.  But you are all correct in
saying that a real compiler does not have this issues in static space. 
But, I have ran into some commercial vendors that deny this behavior and
had to get them to support proper initialization of static space.  The
problem of initialization can get worse when you introduce shared
libraries that have static initialization requirements.  It was a
warning  and am glad you all have not had the same experience with this
as I have.  Maybe if I get a chance, I will send our a snippet of code
that can help explain this better.

Thanks,
Dave



-- 
-----------------------------------------------------------------
David Lucas                    |  mailto:dlucas@checkfree.com
Staff Software Engineer        |                                  
Systems Software Development   |  My opinions are IMHO.
OFX Server Devl 08-126         |                                  
                               |
CheckFree Corporation          |  Work#  614.825.3511            
8275 High Street               |  Fax#   614.825.3104            
Columbus, OH 43235             |  http://www.checkfree.com
-----------------------------------------------------------------

Re: How EGCS with multi-threaded compliance?

[Alexandre Oliva]

David Lucas writes:

>> On any Real System, the mutex object is correctly initialized
>> by the runtime loader before any static constructors are run.
>> That is, the zero value is a valid, unlocked mutex.

> But if the function using the static object (mutex) is being called from
> static space, and not after main starts (which at that point all statics
> are guarenteed initialized), then a chicken and egg condition could
> occur.  =-)

Nope, because zero-initialization takes place before any dynamic
initialization.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: How EGCS with multi-threaded compliance?

[Alexandre Oliva]

Nathan Myers writes:

> Most of the "overhead" could be packed into a single (short) function.

Agreed.  In fact, in the usual general case (i.e., except when the
function is first called), this wouldn't introduce absolutely any
additional run-time overhead.

> The space overhead is little different from what you have now.  
> Probably a single mutex would be sufficient for all the static 
> locals.

Only if the mutexes are reentrant, otherwise the code below would
dead-lock.

struct foo {
  foo() {
    static foo bar;
  }
};

main() {
  static foo bar;
}

Although this particular example might seem uncommon, this might
happen whenever a constructor calls a function with a static variable.
So we should really have per-variable mutexes, unless they're
re-entrant.

Furthermore, sharing a single mutex for unrelated static variables
might introduce possibly unexpected synchronization problems.  (if A
waits for B, but B won't complete because A is holding the
initialization mutex, for instance).

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: How EGCS with multi-threaded compliance?

[Ulrich Drepper]

dlucas@checkfree.com (David Lucas) writes:

> But if the function using the static object (mutex) is being called from
> static space, and not after main starts (which at that point all statics
> are guarenteed initialized), then a chicken and egg condition could
> occur.  =-)

No, the bss section is initialized to zeroes even before the
application (or the DL, resp) gets control.  You must have very little
confidence in the competence of the people developing Unix systems.

-- Uli
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: How EGCS with multi-threaded compliance?

[David Lucas]

Nathan Myers wrote:
> 
> David Lucas <dlucas@checkfree.com>
> > Just an observastion, but some compilers do not even guarentee that
> > init_lock will be initialized before the use of f_initialize_a, thus a
> > possible uninitialized Mutex object.
> 
> On any Real System, the mutex object is correctly initialized
> by the runtime loader before any static constructors are run.
> That is, the zero value is a valid, unlocked mutex.

But if the function using the static object (mutex) is being called from
static space, and not after main starts (which at that point all statics
are guarenteed initialized), then a chicken and egg condition could
occur.  =-)

Later,
Dave

-- 
-----------------------------------------------------------------
David Lucas                    |  mailto:dlucas@checkfree.com
Staff Software Engineer        |                                  
Systems Software Development   |  My opinions are IMHO.
OFX Server Devl 08-126         |                                  
                               |
CheckFree Corporation          |  Work#  614.825.3511            
8275 High Street               |  Fax#   614.825.3104            
Columbus, OH 43235             |  http://www.checkfree.com
-----------------------------------------------------------------

Re: How EGCS with multi-threaded compliance?

[Nathan Myers]

David Lucas <dlucas@checkfree.com>
> Just an observastion, but some compilers do not even guarentee that
> init_lock will be initialized before the use of f_initialize_a, thus a
> possible uninitialized Mutex object.

On any Real System, the mutex object is correctly initialized
by the runtime loader before any static constructors are run.
That is, the zero value is a valid, unlocked mutex.  

Code that runs on losing systems is less efficient.  But isn't
that a tautology?  

Nathan Myers
ncm@cantrip.org  http://www.cantrip.org/

Re: How EGCS with multi-threaded compliance?

[Nathan Myers]

[ multithreaded static inits: ]
> >   void f()
> >   {
> >     static A a;
> >   }
> 
> > The constructor for 'a' is supposed to run the first time you enter f().
> 
> Actually, it is supposed to run the first time control passes through
> the declaration-statement, unless the object is initialized together
> with namespace-scope objects.
> 
> Since there's no requirement in the standard about making this
> thread-safe, and, in fact, the C++ Standard does not talk about
> thread-safety at all, I don't think compilers should care about this,
> since it *is* possible to perform a similiar initialization in a
> thread-safe manner:

There's no requirement for thread-safety anywhere, so why have it at all?
Because users want it.
 
> Of course, a compiler might generate this code implicitly, but I don't 
> think I would appreaciate that much hidden overhead.
 
Most of the "overhead" could be packed into a single (short) function.
The result looks vaguely like:

f()
{
  static struct { char x[sizeof A]; bool inited; } a;  
  if (!a.inited) __init_static(a.x, &_A_ctor, &a.inited);
}

The space overhead is little different from what you have now.  
Probably a single mutex would be sufficient for all the static 
locals.

In general, for thread-safety the compiler should lock for
invisible activities that are not thread-safe, so that libraries
that don't have obvious violations can easily be adopted into an
mt program.

Nathan Myers
ncm@cantrip.org

Re: How EGCS with multi-threaded compliance?

[David Lucas]

Just an observastion, but some compilers do not even guarentee that
init_lock will be initialized before the use of f_initialize_a, thus a
possible uninitialized Mutex object.
I would suggest even making the Mutex heap based and maybe use a double
lock pattern of some sort.   It can get real tricky in static space. 
;-)

> static Mutex init_lock;
> inline A& f_initialize_a()
> {
>   static A *a = 0;
>   if (!a) {
>     Lock lock(init_lock); // released when lock goes out of scope
>     if (!a)
>       a = new A();
>   }
>   return *a;
> }
> 
> void f() {
>   A& a = f_initialize_a();
> }

Later,
Dave


-- 
-----------------------------------------------------------------
David Lucas                    |  mailto:dlucas@checkfree.com
Staff Software Engineer        |                                  
Systems Software Development   |  My opinions are IMHO.
OFX Server Devl 08-126         |                                  
                               |
CheckFree Corporation          |  Work#  614.825.3511            
8275 High Street               |  Fax#   614.825.3104            
Columbus, OH 43235             |  http://www.checkfree.com
-----------------------------------------------------------------

Re: How EGCS with multi-threaded compliance?

[John Carr]

> The constructor for 'a' is supposed to run the first time you enter f().
> This requires a lock (or good luck) in MT code.  Does egcs (or any compiler) 
> generate such a lock?  

Recent Digital UNIX C++ compilers generate thread-safe calls to constructors.

Re: How EGCS with multi-threaded compliance?

[Alexandre Oliva]

Nathan Myers writes:

> Dirk Broer wrote:

>> I'm searching for a C++ compiler that is multi-thread compliance.

> Aren't we all...  An area most compilers haven't got right yet is

>   void f()
>   {
>     static A a;
>   }

> The constructor for 'a' is supposed to run the first time you enter f().

Actually, it is supposed to run the first time control passes through
the declaration-statement, unless the object is initialized together
with namespace-scope objects.

Since there's no requirement in the standard about making this
thread-safe, and, in fact, the C++ Standard does not talk about
thread-safety at all, I don't think compilers should care about this,
since it *is* possible to perform a similiar initialization in a
thread-safe manner:

static Mutex init_lock;
inline A& f_initialize_a()
{
  static A *a = 0;
  if (!a) {
    Lock lock(init_lock); // released when lock goes out of scope
    if (!a)
      a = new A();
  }
  return *a;
}

void f() {
  A& a = f_initialize_a();
}

Of course, a compiler might generate this code implicitly, but I don't 
think I would appreaciate that much hidden overhead.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: How EGCS with multi-threaded compliance?

[Nathan Myers]

Dirk Broer wrote:
> 
> I'm searching for a C++ compiler that is multi-thread compliance.

Aren't we all...  An area most compilers haven't got right yet is


  void f()
  {
    static A a;
  }

The constructor for 'a' is supposed to run the first time you enter f().
This requires a lock (or good luck) in MT code.  Does egcs (or any compiler) 
generate such a lock?  

Nathan Myers
ncm@cantrip.org

Re: How EGCS with multi-threaded compliance?

[Mike Stump]

> From: "Dirk Broer" <Dirk.Broer@gsfc.nasa.gov>
> To: "EGCS" <egcs@cygnus.com>
> Date: Fri, 3 Apr 1998 18:14:55 -0500

> I'm searching for a C++ compiler that is multi-thread compliance.

I suspect that g++ can do what you want.

> Under a high context switch environment g++ consistently fails.

This statement doesn't have enough detail for us to help you.

For example, if you use fopen, and your environment provides an fopen
that isn't mt safe, then calls to it in C++ (as compiled with g++) in
an mt situation are wrong and will fail.

I don't offhand know of a bug that you are referring to, so I cannot
comment further.

Show us how it fails, show us why.  If you do that, we may be able to
fix it for you.

> Is EGCS better?  Especially the c++ parts?

egcs is better in some respects.

I am very interested in mt type bugs, as I work for a company that
does mt OSes.  I maintained the official g++ bug repository for 5 or
so years, and in all that time, I don't recall seeing any/many bug
reports relating to mt issues.


As a side note, egcs g++ has had a bit of work on exception handling,
and we recently have been improving that to make it thread safe.