Re: threadsafeness at egcs1.0.3 and 1.1

Re: threadsafeness at egcs1.0.3 and 1.1

[Mike Stump]

> Date: Fri, 10 Jul 1998 23:03:51 -0400
> From: Ben Scherrey <scherrey@gte.net>
> To: Mike Stump <mrs@wrs.com>
> CC: egcs@cygnus.com

> Whoa! Someone said manual. Where do I get one?????
> 	...or is this some kind of sick joke?

544 pages of manual, and you didn't read it all yet?  Talk about lead
a horse to water...  You can either order one from the FSF, or print
one up yourself.

The sources are in *.texi in the source tree.  I usually just refer to
the .texi file, as it is the more accurate and up-to-date.  I have a
printed copy from the FSF, if I want to do bulk reading or touch
paper.

To print it up yourself, you will need tex and a really good
(reliable) postscript printer (one that errors every 10 pages won't
cut it).

Re: threadsafeness at egcs1.0.3 and 1.1

[Mike Stump]

I don't have enough of a clue, I defer to your expertise.  Thanks for
the clue, I'll try and remember it.

> From: Ulrich Drepper <drepper@cygnus.com>
> Date: 13 Jul 1998 16:21:37 -0700

> No, this is certainly wrong.

Re: threadsafeness at egcs1.0.3 and 1.1

[Mike Stump]

> To: egcs@cygnus.com
> Date: 10 Jul 1998 20:24:11 -0700
> From: Ulrich Drepper <drepper@cygnus.com>
> Stamped: newsgate-cygnus

> martin@mira.isdn.cs.tu-berlin.de (Martin von Loewis) writes:

> > int f()
> > {
> >   static int i = get_some_value();
> >   return i;
> > }

> long).  Plus there is the problem of handling this case if no
> threaded program is used.  (Note that it isn't possible to have a
> simple "not done"/"done" flag since the second thread arriving must
> not return from the get_some_value call until the first did and this
> requires interaction with the thread package.  Busy waiting is no
> option since the waiting thread might have a higher priority.)

No, this is defined in C++ as i having the value zero on the second
call until someone starts changing i.  The implementation is required
to not block, pend or busy wait.  We can extend this out to threaded
apps uniformly.  The setting and testing of the single flag that
controls initialization should be critical regioned.

But yes, even when we do all this, it doesn't have nice semantics in
beefy threaded programs, unless you use sigatomic_t and volatile.

Re: threadsafeness at egcs1.0.3 and 1.1

[Ulrich Drepper]

mrs@wrs.com (Mike Stump) writes:

> No, this is defined in C++ as i having the value zero on the second
> call until someone starts changing i.  The implementation is required
> to not block, pend or busy wait.  We can extend this out to threaded
> apps uniformly.  The setting and testing of the single flag that
> controls initialization should be critical regioned.

No, this is certainly wrong.  The handling must be as for recursive
mutexes.  With them it is allowed for one thread to allocate the mutex
as often as it wants.  It is used in situations where a certain region
is protected using a mutex and calling one function in the region
might call another one.

A different thread has to wait to get the mutex and this is exactly
what has to happen here.

Assume this:

void
very_important_logging (string s)
{
  static int pid = my_getpid ();
  if (pid == 0)
    /* Recursive call, don't do anything.  */
    return;
  cout << process_name[pid] << ": " << s << endl;
}

If my_getpid() can lead to an error which results in calling
very_important_logging again the value of `pid' is 0 as you said and
the thread must not block.  In this case it simply returns and might
do some reasonable work (maybe terminate the program or whatever).

If a second thread would enter the scene which the other thread
executes the my_getpid function it would simply fail to print anything
and return and we loose an important message.


I.e., given your interpretation (which is not founded by the standard
since it does not handle threads at all) the value 0 would signal two
things: the own thread executes the initializer and another thread
executes the initializer.  This is the differenciation made in the
POSIX standard at it makes sense.  Your interpretation wouldn't allow
use to differentiate these two cases.


On the other hand making the call to the initializer similar to a
pthread_once call would mean that we a) can differentiate the cases,
and b) keep the semantic of any code as if it would run in single
threaded programs.

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

Re: threadsafeness at egcs1.0.3 and 1.1

[Martin von Loewis]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]

> > > int f()
> > > {
> > >   static int i = get_some_value();
> > >   return i;
> > > }
> 
[one thread initialising, and the other one entering]
> 
> No, this is defined in C++ as i having the value zero on the second
> call until someone starts changing i.  The implementation is required
> to not block, pend or busy wait.

No, this is undefined:

>> If control re­enters the declaration (recursively) while the object
>> is being initialized, the behavior is undefined.

Even though it says "(recursively)", I'd read that as 'access is
undefined while initialization is in progress'. So blocking in a MT
context seems acceptable.

Furthermore, the second thread must not also perform the
initialization, because i is initialized "before its block is first
entered".

Also, just skipping initialization (and thus accessing the
zero-initialized state) is not in the spirit of the spec. If
initialization is not complete, "it will be tried again the next time
control enters the declaration". Formally, this applies only to
initializations left through exceptions, but providing this semantics
in the MT case seems like a reasonable extension.

In short, g++ currently doesn't comply with the standard (no
exception-awareness), so this needs to be changed, anyway.
Considering MT here seems seems like a good idea to me, at
least as an option.

Regards,
Martin

Re: threadsafeness at egcs1.0.3 and 1.1

[Mike Stump]

> Date: Thu, 09 Jul 1998 16:20:11 -0400
> From: Thomas Wagner <honus+egcs@cmu.edu>
> To: egcs@cygnus.com

> I haven't been able to find any information of the threadsafeness of
> C++ with v1.0.3.

EH is not thread safe in 1.0.3.  Use a snapshot, or 1.1.  Local static
objects are not thread safe in 1.0.3, nor in 1.1.

If your truely interested in this topic, you can collect the
information and put a new section into the manual...

Re: threadsafeness at egcs1.0.3 and 1.1

[Ben Scherrey]

Whoa! Someone said manual. Where do I get one?????
	...or is this some kind of sick joke?

	Ben Scherrey

Mike Stump wrote:
> If your truely interested in this topic, you can collect the
> information and put a new section into the manual...

threadsafeness at egcs1.0.3 and 1.1

[Thomas Wagner]

I haven't been able to find any information of the threadsafeness of C++
with v1.0.3.  I know about the threadsafeness of the SGI STL, but what about
internal compiler issues like exceptions.  Are they threadsafe?  If not,
will they be in 1.1?

Thanks,
Tom
--
honus+@cmu.edu, Principal Software Engineer, the NetBill project
Information Networking Institute, Carnegie Mellon University
"Always there's that space between what you feel and what you do,
   and in that gap all human sadness lies." -George Rodrigue

Re: threadsafeness at egcs1.0.3 and 1.1

[Jeffrey A Law]

  In message < 2353046752.900001211@DUCAT.INI.CMU.EDU >you write:
  > internal compiler issues like exceptions.  Are they threadsafe?  If not,
  > will they be in 1.1?
Exceptions will be thread safe in egcs-1.1, but not egcs-1.0.3.
jeff

Re: threadsafeness at egcs1.0.3 and 1.1

[Martin von Loewis]

> I haven't been able to find any information of the threadsafeness of C++
> with v1.0.3.  I know about the threadsafeness of the SGI STL, but what about
> internal compiler issues like exceptions.  Are they threadsafe?  If not,
> will they be in 1.1?

Exception handling is not thread-safe in 1.0, it will be in 1.1
(provided you have a supported thread library on your system).

There is a minor issue left: initialization of local static objects,
as in

int f()
{
  static int i = get_some_value();
  return i;
}

If two threads call f concurrently, initialization might be performed
twice. Since this can be handled on the application level in many
cases, it is not considered a serious problem (by some).

If get_some_value produces an exception, the code that g++ emits does
not conform with the standard, so this needs to be rewritten, anyway.
Anybody looking into it might consider thread-safety here, as well.

Regards,
Martin

Re: threadsafeness at egcs1.0.3 and 1.1

[Ulrich Drepper]

martin@mira.isdn.cs.tu-berlin.de (Martin von Loewis) writes:

> int f()
> {
>   static int i = get_some_value();
>   return i;
> }
> 
> If two threads call f concurrently, initialization might be performed
> twice. Since this can be handled on the application level in many
> cases, it is not considered a serious problem (by some).

This is a case for calling pthread_once which is associated with a
quite high cost (the pthread_once_t is normally at least two words
long).  Plus there is the problem of handling this case if no threaded
program is used.  (Note that it isn't possible to have a simple "not
done"/"done" flag since the second thread arriving must not return from
the get_some_value call until the first did and this requires
interaction with the thread package.  Busy waiting is no option since
the waiting thread might have a higher priority.)

I see this case as a real boundary case which probably shouldn't
handled at all and the use of non-const initializing of static
variables should be outlawed.

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

Re: threadsafeness at egcs1.0.3 and 1.1

[Martin von Loewis]

> This is a case for calling pthread_once which is associated with a
> quite high cost (the pthread_once_t is normally at least two words
> long).

Interesting. There is an additional problem in local static
initializers for C++: If initialization throws an exception,
initialization is considered incomplete, and should be re-tried on the
next call (of course, after destructors of subobjects have been
called). 

So pthread_once doesn't really work here: We can't have once routines
that fail. Instead, we would need to duplicate glibc pthread_once with
a mutex and a condition, except that it restores the once_t to NEVER
instead of DONE in case of an exception.

This would also simplify linking to non-threaded code: the libgcc2
__cpp_once function would just call the initializer in the
non-threaded case.

Regards,
Martin

Re: threadsafeness at egcs1.0.3 and 1.1

[Nicholas Lee]

On 10 Jul 1998 20:24:11 -0700, you wrote:

>martin@mira.isdn.cs.tu-berlin.de (Martin von Loewis) writes:
>
>> int f()
>> {
>>   static int i = get_some_value();
>>   return i;
>> }
>> 
>> If two threads call f concurrently, initialization might be performed
>> twice. Since this can be handled on the application level in many
>> cases, it is not considered a serious problem (by some).
>
[...]
>I see this case as a real boundary case which probably shouldn't
>handled at all and the use of non-const initializing of static
>variables should be outlawed.

Have you read Meyer's comment in MEC++, about function static vs class
static? (pg 133-134)

His basic comment is that function statics have value in that they nail
down the point of initialisation a some function call time.  

Nicholas

--
        "I reserve the right to contradict myself" 
n.lee with math.auckland.ac in nz
NO commercial email please! No SPAM for me.

Re: threadsafeness at egcs1.0.3 and 1.1

[Ulrich Drepper]

n.lee@math.auckland.ac.nz (Nicholas Lee) writes:

> His basic comment is that function statics have value in that they nail
> down the point of initialisation a some function call time.  

I don't know whether I understand this sentence.  But it seems this is
exactly what we are talking about.  We have to initialize the function
static, but how is the question.  It's no problem in single-threaded
programs, we are talking about multi-threaded programs.

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

Re: threadsafeness at egcs1.0.3 and 1.1

[Nicholas Lee]

On 13 Jul 1998, Ulrich Drepper wrote:

> n.lee@math.auckland.ac.nz (Nicholas Lee) writes:
> 
> > His basic comment is that function statics have value in that they nail
> > down the point of initialisation a some function call time.  
> 
> I don't know whether I understand this sentence.  But it seems this is
> exactly what we are talking about.  We have to initialise the function
> static, but how is the question.  It's no problem in single-threaded
> programs, we are talking about multi-threaded programs.

He compares it with Class and global statics where the order of
initialisation is fixed within translation units, but not across them. 

Class Static initialisation order might be even more of a problem in a
threaded application, where different threads might enter different
translation units at different times or at the same time. 


Nicholas

--
	"I reserve the right to contradict myself."

Nicholas Lee (Li Peng Ming)  n.lee with math.auckland.ac in nz
Auckland University, New Zealand	

Re: threadsafeness at egcs1.0.3 and 1.1

[Ulrich Drepper]

martin@mira.isdn.cs.tu-berlin.de (Martin von Loewis) writes:

> This would also simplify linking to non-threaded code: the libgcc2
> __cpp_once function would just call the initializer in the
> non-threaded case.

As I've said, you cannot reimplement the function without knowing
exactly how the thread package used works.  If you are not going for
efficiency you can use a mutex which is very expensive and still has
to be adapted for the platform + used thread package.  E.g., what
happens on Solaris where two thread packages are in use?

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