скажем, у нас есть класс C++, например:
class MyClass
{
void processArray( <an array of 255 integers> )
{
int i ;
for (i=0;i<255;i++)
{
// do something with values in the array
}
}
}
и один экземпляр класса, например:
MyClass myInstance ;
и 2 потока, которые вызывают метод processArray этого экземпляра (в зависимости от того, как система выполняет потоки, возможно, в совершенно нерегулярном порядке). В этой области не используется блокировка мьютекса, поэтому могут входить оба потока.
Мой вопрос: что происходит с i? Имеет ли каждая область видимости потока свой собственный «i» или каждый входящий поток изменяет i в цикле for, в результате чего i все время странным образом меняется.





i размещен в стеке. Поскольку каждый поток имеет свой собственный отдельный стек, каждый поток получает свою собственную копию i.
Технически это называется переменной стека (из-за ее объема). Регистры - это просто деталь реализации, которая не имеет отношения к делу.
Поскольку i - локальная переменная, она хранится в собственном частном стеке потока. Следовательно, вам не нужно защищать i критической секцией.
Как сказал Адам, i - это переменная, хранящаяся в стеке, и аргументы передаются, так что это безопасно. Когда вам нужно быть осторожным и применять мьютексы или другие механизмы синхронизации, это если вы обращались к общим переменным-членам в том же экземпляре класса или глобальным переменным в программе (даже со статикой с ограниченной областью видимости).
Будь осторожен. В приведенном примере метод processArray выглядит как повторно въезжающий (непонятно, что происходит в // что-то делаем со значениями в массиве). Если это так, гонка не происходит, пока два или более потока вызывают ее одновременно, и поэтому ее можно безопасно вызывать без какого-либо механизма блокировки. Чтобы обеспечить это, вы можете пометить как экземпляр, так и метод квалификатором летучий, чтобы пользователи знали, что блокировка не требуется. Опубликована интересная статья Андрея Александреску о летучий квалификатор и о том, как его можно использовать для написания правильных многопоточных классов. Статья размещена здесь: http://www.ddj.com/cpp/184403766
технически это, вероятно, будет в реестре, но идея есть.