build, but I didn't have any compiler optimizations turned on. Will
definitely retry it with them turned on. However, one other reason I
opted against std::vector, was the semantics. A multi-dimensional
vector<vector<vector<vector<int> > > > > vec_a(5,..... ad inifintum.
On Nov 29, 11:12 pm, Joseph M. Newcomer <newco...@flounder.com> wrote:
See below
On Thu, 29 Nov 2007 20:10:39 -0800 (PST), flowstudi...@gmail.com wrote:
On Nov 29, 7:10 pm, Joseph M. Newcomer <newco...@flounder.com> wrote:
The code below is full of bugs and will not compile, but if corrected, it would work. (For
example, WriteToArray takes 4 parameters in the declaration, and 3 parameters in the
implementation, using the value a twice, once as the array name, once as a parameter)
Yes, it wasn't meant to be useable code, but I thought it would help
explain a bit more what I was thinking vs just "Are static array
pointers thread safe /NT".
*****
The concept that static array pointers may or may not be safe is an irrelevant discussion.
All you care about is the information referenced during an operation, and whether or not
it is thread safe. Whether it is referenced by a pointer, or directly, or through
nineteen levels of indirection is irrelevant. What matters is whether or not the access
path and the value are thread-safe, and the answer is, generally, "never". There are
limited situations in which you might get away with this, such as "write once constants",
where you set values and never modify them, or simple read/write of aligned data where the
order of modification is irrelevant and the nondeterministic effects do not impact the
algorithm, but generally, data access is not thread safe unless you provide the safety
yourself.
****
Depends on what you mean by "thread safe". Assuming the values are integers, and DWORD
aligned, it is certainly true that you will not have errors if you just have threads write
fooInstance->writeToArray(1, 2, 3, 5);
while another thread does
fooInstance->writeToArray(1, 2, 3, 7);
the value in a[1][2][3] will be either 5 or 7, and you won't know which. But you cannot
read-and-modify any element of the array, e.g., you cannot do
fooInstance->writeToArray(1, 2, 3, fooInstance->readFromArray(1, 2, 3) + 1);
and expect it will work correctly. It won't. That *does* require explicit
synchronization.
I asked Doug this same question, but could you define what you mean by
it not working correctly (app crash, old value, reading junk, etc)?
What I mean by thread safe for this application is it not causing any
memory errors that would result in application failures. Your second
example was what I was wanting to do, if it returned an old value,
that would be ok.
****
You might get obsolete values, you might produce erroneous values, updated values will be
overwritten by obsolete values, and so on. If the obsolete values or erroneous values
would affect the correctness of the access to the data (not the data itself), then
definitely you will get an app crash. So it depends on how the pointer value is set and
manipulated.
****
Multiple creates could cause immense problems, but like most examples we see here, all the
really critical and important information is omitted, such as how createArray works.
The idea is it would be initialized once at application startup.
Multiple creates would not be used. I went into more detail the
direction I was going and why in my previous reply to Doug.
****
That's a "write once constant", and therefore becomes irrelevant to the discussion of
thread safety because there is no concurrent modification. Thread safety is only an issue
when threads can modify values concurrent with other threads reading them. If the use of
stale data and the resetting of new values to use stale data don't affect your algorithm,
you don't need to lock. We discovered interesting algorithms in our big 16-way
multiprocessor back in 1976 or so, such as no need to lock values at boundaries of certain
kinds of convolution algorithms (where, for partition A to compute the value at the border
of A|B, some values from the B partition must be read and modified. The effect is a
slight anomaly in early iterations which quickly converges to enough accuracy after a few
hundred iterations that the errors are below the significance threshold required for the
real-world result)
****
int (*foo::a)[26][26];
****
Using a single static like this is a bit strange; it means you can never have more than
one instance of this object anywhere. I presume the goal is a singleton class.
Yes, the goal is to have this be singular. I'm not an expert on the
singleton pattern, but I believe it could be looked at like that yes.
The use of old-fashioned C in a modern environment is more than a little strange also; why
are you not using bounds-checked classes like std::vector? None of this is bounds-safe.
****
The application requires speed to be a priority for reading and
writing to the array. Profiling std::vector vs the above showed vector
to be 3x slower for writes and 2.5x for reads. Bounds-safety can be
checked by the read-write functions using an enum or static const int
defining MAX_SIZE.
****
When you measure performance, it is only valid to measure it in the release version. It
is never valid to measure performance in the debug version, and it is problematic if
measuring performance of unoptimized code is indicative of anything other than the need to
turn on compiler optimizations. Often, bounds checks are optimized away by value
propagation and assertion propagation (which has nothing to do with the ASSERT statement).
****
As for the rest of the corrections below, yes, you got me. I wasn't be
careful and was more trying to convey a general idea rather than
presenting flawless code. My bad, I should have communicated this more
clearly. Thanks for your comments Joe.
John
void foo:createArray(){
a = new int[26][26][26];
}
void foo:writeToArray(int a, int b, int c){
a[a][b][c] = d;
}
****
I'm assuming you meant
void foo:writeToArray(int b, int c, int d, int e) {
a[b][c][d] = e;
****
void foo::readFromArrat(int a, int b, int c){
return a[a][b][c];
}
****
I'm assuming you meant
int foo::readFromArray(int b, int c, int d) {
return a[b][c][d];}
****
Joseph M. Newcomer [MVP]
email: newco...@flounder.com
Web:http://www.flounder.com
MVP Tips:http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newco...@flounder.com
Web:http://www.flounder.com
MVP Tips:http://www.flounder.com/mvp_tips.htm