John said:
Interesting so it seems that the compiler(c/c++)interpreter(perl,
python)/vm(java) doesn't do this?
It is impossible for a language, vm, or operating system to avoid
threading problems without the programmer's help, except by trivial
means (eg. preventing you from having them at all).
The power of threading is entirely tied up with the features the
environment gives to the developer, and those features come with a risk.
At one extreme is the CP/M model. You start a new program only when you
finish the previous one. So the only communication between them is a
file the first one leaves behind, that the second can look at.
Next is separate processes. If you launch a second process, by default,
they're independent, and not likely to get into trouble. But you can
build pipes or shared memory, or sockets between them, and then you have
to worry about race conditions.
Next is threads, within a single process. At this point, you can share
(global) variables between them, or you can have objects known to both
when the thread is launched. The system cannot tell which ones are
deliberate and which ones are accidental. So a language might give
extra keywords to tell the compiler that certain things should be
protected in certain ways. Or it might give a way to declare a
"per-thread global" that acts like a global to each thread, but is
actually two independent variables from the process point of view.
The only real reason threads are singled out is it's easier to collide
by mistake. But that's also what makes it efficient to "collide" on
purpose.
DaveA