Temporary varriables and thread safety

We are evaluating some old code that was written as part of our math
library.
This code uses some optimizations that I'm not sure are necessary or
safe, but is a source of debate between my coworkers.

Method 1 includes a temporary storage varriable at class scope.
Method 2 includes a temporary storage varriable at method scope.
Method 3 includes a temporary static storage varriable at method scope.

Are any of the methods better than the others in terms of speed and
thread safety?
This question is _better_ asked in a newsgroup that actually deals with
threading: comp.programmin g.threads. C++ does not have support, not does
it have any definitions of, threading. The program is assumed to be
single-threaded in C++ standard.

Now, when talking about threads it is essential to identify the data that
can be changed. You didn't say how many threads are accessing what part
of data at some point.
I don't believe method 1 or 3 are thread safe, but I think method 2 may
be too slow for a high-performance library. Is there a method 4 that
we should evaluate?

As an aside, I can't find in the standard where static is addressed in
terms of a member function. Is it true that a static varriable within
a member function exists for all instances?
A static object is a static object regardless of what scope it's in. It's
essentially a singleton.
/// ---- method 1

class vector {
...
private:
vector tempVector;
You simply _physically_ cannot have an object that contains an instance of
its own type.
};
vector::somefun ction() {
Does this one have any return value type?
// writes to tempVector as temporary storage
It is generally _unknown_ here what storage duration 'tempVector' has,
since its storage duration is the same as that of '*this' object. (All
that assuming that the type of 'tempVector' is _not_ the same as the
object that contains it)
}
/// ---- method 2
class vector {
...
};
vector::somefun ction() {
vector tempVector;
// writes to tempVector as temporary storage
This is the most "thread-safe", largely because in many threading models
(if not all), automatic variables are "per-thread".
}

/// --- method 3
class vector {
...
};
vector::somefun ction() {
static vector tempVector;
// writes to tempVector as temporary storage
This is the _least_ "thread-safe", since static objects are usually shared
between all threads.
}

We are evaluating some old code that was written as part of our math
library.
This code uses some optimizations that I'm not sure are necessary or
safe, but is a source of debate between my coworkers.

Method 1 includes a temporary storage varriable at class scope.
Method 2 includes a temporary storage varriable at method scope.
Method 3 includes a temporary static storage varriable at method scope.

Are any of the methods better than the others in terms of speed and
thread safety?
I don't believe method 1 or 3 are thread safe, but I think method 2 may
be too slow for a high-performance library. Is there a method 4 that
we should evaluate?

/// ---- method 1

class vector {
...
private:
vector tempVector;

You simply _physically_ cannot have an object that contains an instance of
its own type.

};

We are evaluating some old code that was written as part of our math
library.
This code uses some optimizations that I'm not sure are necessary or
safe, but is a source of debate between my coworkers.

Method 1 includes a temporary storage varriable at class scope.
Method 2 includes a temporary storage varriable at method scope.
Method 3 includes a temporary static storage varriable at method scope.

Are any of the methods better than the others in terms of speed and
thread safety?
I don't believe method 1 or 3 are thread safe, but I think method 2 may
be too slow for a high-performance library. Is there a method 4 that
we should evaluate?

Chad Zalkin wrote:

We are evaluating some old code that was written as part of our math
library.
This code uses some optimizations that I'm not sure are necessary or
safe, but is a source of debate between my coworkers.

Method 1 includes a temporary storage varriable at class scope.
Method 2 includes a temporary storage varriable at method scope.
Method 3 includes a temporary static storage varriable at method scope.

Are any of the methods better than the others in terms of speed and
thread safety?

This question is _better_ asked in a newsgroup that actually deals with
threading: comp.programmin g.threads. C++ does not have support, not does
it have any definitions of, threading. The program is assumed to be
single-threaded in C++ standard.

Now, when talking about threads it is essential to identify the data that
can be changed. You didn't say how many threads are accessing what part
of data at some point.

I don't believe method 1 or 3 are thread safe, but I think method 2 may
be too slow for a high-performance library. Is there a method 4 that
we should evaluate?

As an aside, I can't find in the standard where static is addressed in
terms of a member function. Is it true that a static varriable within
a member function exists for all instances?

A static object is a static object regardless of what scope it's in. It's
essentially a singleton.

/// ---- method 1

class vector {
...
private:
vector tempVector;

You simply _physically_ cannot have an object that contains an instance of
its own type.

};
vector::somefun ction() {

Does this one have any return value type?

// writes to tempVector as temporary storage

It is generally _unknown_ here what storage duration 'tempVector' has,
since its storage duration is the same as that of '*this' object. (All
that assuming that the type of 'tempVector' is _not_ the same as the
object that contains it)

}
/// ---- method 2
class vector {
...
};
vector::somefun ction() {
vector tempVector;
// writes to tempVector as temporary storage

This is the most "thread-safe", largely because in many threading models
(if not all), automatic variables are "per-thread".

}

/// --- method 3
class vector {
...
};
vector::somefun ction() {
static vector tempVector;
// writes to tempVector as temporary storage

This is the _least_ "thread-safe", since static objects are usually shared
between all threads.

}

To sum up: method 2 is generally thread-safe, method 3 is generally not,
and nothing can be said about method 1.
V

In defence of my own sanity, method 1 was not meant to include itself.
Let's all imagine that the tempVector is now of type foo in all
methods.

The part that I forgot to mention in my haste was that more than one
method will use the temporary storage:
class vector {
void add(); // needs temporary storage
void sub(); // needs temporary storage
void dot(); // needs temporary storage
};

class tempStorage
{
public:
// some data members
};

Now, let's ignore the threadding issue since it is OT.

If add(), sub(), and dot() all need to store some temporary data during
their runtime,
is it more efficient to store this data at class level (constructing
and destructing once per object) or at function level (constructing and
destructing once per function call; potentially many more times).
Well, you forgot something:

Class level: Contruction once. Assignment for each function call.
Function level: Construct & initialisation once per call.
Since add(), sub(), and dot() do not call each other, storing the data
at class level becomes possible. (But then the thread issue comes into
play...)
Indeed. And although you don't need to construct the object, you do
need to assign to it, which may or may not be faster than constructing
and initialising.

Don't forget that it's in automatic storage, not heap... so the memory
is already "allocated" .
What are the pro's and con's of scoping at each level? What can I
trust the compiler to be allowed to optimize? What can I do to help
the compiler optimize?

[..]
Let's all imagine that the tempVector is now of type foo in all
methods.

The part that I forgot to mention in my haste was that more than one
method will use the temporary storage:
class vector {
void add(); // needs temporary storage
void sub(); // needs temporary storage
void dot(); // needs temporary storage
};

class tempStorage
{
public:
// some data members
};

Now, let's ignore the threadding issue since it is OT.

If add(), sub(), and dot() all need to store some temporary data during
their runtime,
is it more efficient to store this data at class level (constructing
and destructing once per object) or at function level (constructing and
destructing once per function call; potentially many more times).
<triallawyer>
Objection: leading!
</triallawyer>

It all depends on how much it takes to construct that object and how big
it actually is. You are forgetting an important element of performance:
make your objects smaller. If you store anything at the object level, you
make it bigger. It may not have effect on the performance in this
particular area of your program, but somewhere else... Which leads me to
another point: do not attempt to optimize before you have a chance to
measure the performance and conclude _whether_ and _where_ the actual
optimization is needed.
Since add(), sub(), and dot() do not call each other, storing the data
at class level becomes possible. (But then the thread issue comes into
play...)

What are the pro's and con's of scoping at each level? What can I
trust the compiler to be allowed to optimize? What can I do to help
the compiler optimize?