Is it safe to locally use arrays, vectors and calloc when multi-threading

Hi everyone,

I have a question about working with threads.
Is it safe to work with locally assigned memory, such as arrays, vectors and memory temporarily created with calloc (or a simillar alloc operation)?
For example, in the code below, there's three such methods.
Is it possible for two threads to exactly simultaneously request memory, which in turn creates a conflict?

Thank you in advance.

Code:

---

int main()
{
    std::vector<std::thread *> threads(4);
    for (int i = 0; i < 4; i++)threads(i) = new std::thread(&MyFunction, this);

    for (int i = 0; i < 4; i++)
    {
        threads[i]->join();
        delete threads[i];
    }
}

void MyFunction()
{
    // METHOD 1: LOCAL ARRAY
    int values1[4] = {1, 2, 3, 4}

    // METHOD 2: LOCAL VECTOR
    std::vector<int> values2;
    for (int i = 0; i < 4; i++)values2.push_back(i + 5);

    // METHOD 3: CALLOC
    int * values3 = NULL;
    values3 = (int *)calloc(4, sizeof(int));
    for (int i = 0; i < 4; i++)values3[i] = i + 10;

    // PERFORM OPERATIONS

  // RELEASE THE MEMORY FROM METHOD 3
    free(values3);
}

---

Quote:

---

is it possible for two threads to exactly simultaneously request memory,

---

Yes.

Although in C++ programs you should use new/delete rather than calloc/malloc/free

Quote:

---

Originally Posted by rmirani

Is it safe to work ... with calloc (or a simillar alloc operation)?

---

I agree with 2kaud.
You schuld leave the using calloc (or a simillar alloc operation) in c-code.
In C++ you have to use new/delete. Better - some already implemented (std) container classes.

I agree with the previous posters, at least if you use C++ version 11 or later.

C++ 11 was a game-changer. Especially concurrency got a much-needed overhaul. Why should you not be able to use standard data structures or allocate memory using calloc simultaneously in several threads without worrying about a system crash? Well, you do not have to, not after C++ 11.

Furthermore, C++ version 20 offers so much concurrency that it is seldom necessary to manage threads explicitly to exploit parallelisms. Most algorithms in the C++ standard library can run in parallel.

Ok, thank you.
I'm indeed using new/delete rather than calloc/malloc/free, but I forgot to explicitly ask for new/delete in the list of possibilities.
As for the C++ version, I'm using Microsoft Visual Studio 2017, which apparently uses C++ 14.16, so I assume that this should be sufficient?
I've never had any issues with the code itself, but it occurred to me today that I should just double-check to see if perhaps there's some hidden bugs.

Quote:

---

Originally Posted by rmirani

Ok, thank you.
I'm indeed using new/delete rather than calloc/malloc/free, but I forgot to explicitly ask for new/delete in the list of possibilities.
As for the C++ version, I'm using Microsoft Visual Studio 2017, which apparently uses C++ 14.16, so I assume that this should be sufficient?
I've never had any issues with the code itself, but it occurred to me today that I should just double-check to see if perhaps there's some hidden bugs.

---

I understand there may be company restrictions. But if you are free to choose, I recommend you update to the latest Visual Studio version and the latest C++ standard. With a reasonable delay, of course, to let things settle in.

I also recommend not using C++ as just a better C. Instead, use C++ as better than its peers, such as Java, C#, Python and Rust, etcetera. And this means preferring the modern features of C++ over its C legacy part.

Quote:

---

I'm using Microsoft Visual Studio 2017, which apparently uses C++ 14.16

---

The current version is VS 2022 which provides support for C++20. The Community version is still free. I suggest you install VS2022. This will happily co-exist with VS2017. It uses the same installer.