Is this simple code thread safe?

[matsp]

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...

32-bit accesses should be fine [on anything but Alpha at least], but yes, partial machine word accesses will need protection unless you know the architecture to be sure that it can do the access without interfering with other data around it.

--
Mats

[Elysia]

The general rule implies that if two threads access the same data (and at least one writes), then it's not thread safe unless you use thread synchronization access.
It's a very good rule to adhere to, since it will avoid race conditions.

[matsp]

Yes, but the original post is actually accessing two different data elements (vec[0] and vec[1]), and the discussion here is if that's safe or not. The conclusion is that it's not always safe, but most machines will be able to access "int" in a single access.

If you can be sure that the processor doesn't touch the data AROUND your access, then single writes are safe without locks.

--
Mats

[Elysia]

As the rule says, however, it is not guaranteed to be safe because both threads access the same object, even though they may access different elements inside that object.

[matsp]

As the rule says, however, it is not guaranteed to be safe because both threads access the same object, even though they may access different elements inside that object.

Ok, so if we have:

short a;
short b;

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

int main()
{
  pthread_t t1, t2;
  pthread_create(&t1, NULL, foo, (void*)&a);
  pthread_create(&t1, NULL, foo, (void*)&b);

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

  return 0;
}

Your rule doesn't cover the above, which is still possible to break.

And I'd wager that in an x86 architecture, a with vector<int> vec; &vec[0] and &vec[1] are perfectly fine to be accessed independently without locks. But it's not guaranteed in all architectures.

--
Mats

[Elysia]

You're right, naturally. Thread safety is a difficult thing.
But it's a very good general rule to remember. I think the C/C++ standard mentions such a thing, perhaps even on reads? It defines them as "condition races" I think?

But my was point was, that I would not truly consider it thread safe because it violates the basic rule of never accessing the same object from two or more threads at the same time without synchronization.

[brewbuck]

How could they access the same item? On

Sorry, I misread the code. I thought the call to rand() was computing the index to store at.

[brewbuck]

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

A lot of multithreaded code IS broken, because it assumes that all accesses to basic types are atomic, which is not actually guaranteed at all. And anyway, how would you implement an atomic 16-bit store on an architecture with an 8 bit bus? You can't, unless you mask interrupts and lock the bus. Masking and then unmasking interrupts every time you access a variable would be... dumb.

[Codeplug]

This is a good read on the subject of "word tearing":
http://groups.google.com/group/comp....a9c0ee17e390c/

Tru64 documentation is also an interesting read:
http://h30097.www3.hp.com/docs/base_...7.HTM#gran_sec (3.7 Granularity Considerations)
http://h30097.www3.hp.com/docs/base_...E/DOCU0008.HTM

gg

[CornedBee]

I think the C/C++ standard mentions such a thing, perhaps even on reads?

Neither the C nor the C++ standard currently even have the concept of multiple threads of execution.

[Elysia]

OK, but there was somewhere I've found it mentioned, but can't remember where as usual.