Re: Are static array pointers thread safe?
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".
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.
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.
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.
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