Is this simple code thread safe?

[meili100]

Here is the code in that 2 threads write to a shared vector (to different items in the vector).
I know std::vector is not thread safe, but the 2 threads are writing to different items. I am not sure how vector is implemented. Could there be any potential race condition?

void* foo0(void* vec)
{
  vector<int>* arr = (vector<int>*)vec ;
  int i = (int)(rand()*10);
  arr->at(0) = i;
}

void* foo1(void* vec)
{
  vector<int>* arr = (vector<int>*)vec ;
  int i = (int)(rand()*10);
  arr->at(1) = i;
}

int main()
{
  vector<int> vec;
  vec.push_back(0);
  vec.push_back(0);

  pthread_t t1, t2;
  pthread_create(&t1, NULL, foo1, (void*)&vec);
  pthread_create(&t1, NULL, foo2, (void*)&vec);

  pthread_join(t1, NULL);
  pthread_join(t2, NULL);

  return 0;
}

[vart]

And Why not to pass pointer to int instead?

(void*)&vec[0] and (void*)&vec[1]

It should be fine like now as well - but it too complicates the access to the member in the thread function, you may even have same function for both threads...

[brewbuck]

Here is the code in that 2 threads write to a shared vector (to different items in the vector).
I know std::vector is not thread safe, but the 2 threads are writing to different items. I am not sure how vector is implemented. Could there be any potential race condition?

Accesses to any type except char and sig_atomic_t (if present) are not guaranteed to be atomic. That means that if both threads choose to write to the same location in the vector simultaneously, they may corrupt each other's writes.

On an architecture which supports fundamental multi-byte access to memory (i.e., most architectures) this problem will not happen in practice. But if you were on, for instance, an 8-bit architecture where the compiler implements 16-bit types for convenience, stores to a 16-bit variable might be implemented as multiple memory stores, so in theory, one thread could interrupt the other in mid-store, corrupting the data.

Incidentally the problem has nothing to do with std::vector<int> but is an underlying issue of the language.

[meili100]

Thanks. I agree with you. But it indeed doesn't matter whether it passes an int or a vector. The question is: Is this way thread safe? One of my friends told me this is thread safe, there is no need to use a lock to protect the accessing of the shared vector.

And Why not to pass pointer to int instead?

(void*)&vec[0] and (void*)&vec[1]

It should be fine like now as well - but it too complicates the access to the member in the thread function, you may even have same function for both threads...

[meili100]

Thanks, but I don't quite get you. The 2 items in the vector do not share any bytes in memory, regardless of the architecture, don't they?

Accesses to any type except char and sig_atomic_t (if present) are not guaranteed to be atomic. That means that if both threads choose to write to the same location in the vector simultaneously, they may corrupt each other's writes.

On an architecture which supports fundamental multi-byte access to memory (i.e., most architectures) this problem will not happen in practice. But if you were on, for instance, an 8-bit architecture where the compiler implements 16-bit types for convenience, stores to a 16-bit variable might be implemented as multiple memory stores, so in theory, one thread could interrupt the other in mid-store, corrupting the data.

Incidentally the problem has nothing to do with std::vector<int> but is an underlying issue of the language.

[VirtualAce]

To be safe you should either mutex access to the vector or protect it with a critical section.

[brewbuck]

Thanks, but I don't quite get you. The 2 items in the vector do not share any bytes in memory, regardless of the architecture, don't they?

Your threads are accessing the vector at random. Why do you think they couldn't randomly access the same item at the same time?

[bithub]

Your threads are accessing the vector at random. Why do you think they couldn't randomly access the same item at the same time?

How could they access the same item? One thread is accessing the first index, while the second thread is accessing the second index.

Whether or not this is thread safe depends on the implementation of the vector. What you are doing is probably safe, but you would need to see the vector code to know for sure. I checked the implementation on VC8 and you are safe with that.

[vart]

void* foo(void* arg)
{
   int* i = (int*)(arg);
   *i = rand()*10;
}

int main()
{
  vector<int> vec;
  vec.push_back(0);
  vec.push_back(0);

  pthread_t t1, t2;
  pthread_create(&t1, NULL, foo, (void*)&vec[0]);
  pthread_create(&t1, NULL, foo, (void*)&vec[1]);

  pthread_join(t1, NULL);
  pthread_join(t2, NULL);

  return 0;
}

[CornedBee]

There's currently absolutely no reliable guarantees with regard to standard library thread safety. In practice, the basic POSIX guarantee holds in all implementations: reading is safe, modifying (in the sense of modifying the actual container, not just its elements) must be synchronized.

However, because the two ints are adjacent, you actually might get in trouble on platforms that do their memory access in 64-bit units only, like the Alpha.

[vart]

There's currently absolutely no reliable guarantees with regard to standard library thread safety. In practice, the basic POSIX guarantee holds in all implementations: reading is safe, modifying (in the sense of modifying the actual container, not just its elements) must be synchronized.

However, because the two ints are adjacent, you actually might get in trouble on platforms that do their memory access in 64-bit units only, like the Alpha.

So you want to tell, that if I pass some pointer to the thread, and it starts to modify data using this pointer I cannot be sure that the data will not be corrupted by other thread that tries to access some other data that is by chance adjusted to the data I modify?

This is some very new idea for me...

[matsp]

So you want to tell, that if I pass some pointer to the thread, and it starts to modify data using this pointer I cannot be sure that the data will not be corrupted by other thread that tries to access some other data that is by chance adjusted to the data I modify?

This is some very new idea for me...

Yes, that would be POSSIBLE. However, I do believe that even the early Alpha processors, whilst having a 64-bit BUS, would actually perform longword accesses, which is 32-bit [I don't know this for sure, but that is from what I could find in 2 minutes googling].

It is CERTAINLY true that there are machines that can't use for example 16 bit numbers without doing something along the lines of:

void writeshort(long *ptr, short x)
{
   short *p;
   p = ptr & ~3;
   if ((int)ptr & 2)  *p = (*p & 0xFFFF0000) | (value & 0xFFFF);
   else *p = (*p 0xFFFF) | (value << 16);
}

Obviously, this would be implemented in machine code by the compiler, not as a user-function in C - I wrote it that way to make it eas{y,ier} to understand.

--
Mats

[vart]

Obviously, this would be implemented in machine code by the compiler, not as a user-function in C

Shouldn't it be implemented as atomic operation? Otherwise a lot of multi-threaded code will be broken

[matsp]

Shouldn't it be implemented as atomic operation? Otherwise a lot of multi-threaded code will be broken

That was the entire point of Cornedbee's post: It is not, by itself, an atomic operation (because it consists of separate read and write operations). It would need to be protected by some sort of lock mechanism to make sure that the set of instructions:

// pseudo risc assembler:
    load  p, temp1
    load  x, temp2
    and   temp1, 0xFFFF0000
    and   temp2, 0xFFFF
    or      temp1, temp2
    store p, temp1

If the memory location pointed to by p changes during this sequence, then undefined behaviour occurs.

But machines that have this problem with 32-bit values are VERY rare.

--
Mats

[vart]

But machines that have this problem with 32-bit values are VERY rare.

That implies that ANY 32-bit access should be protected on these machines - because I cannot know what lies around my vars, and who will access that memory... This is really strange idea...