Здравствуйте.
Подскажите, пожалуйста.

Написал полуАвтоматический класс-оболочку для мутексов. Через деструктор в конце области действия мутекс освобождается.  Возникли сомнения по поводу return в том, что произойдет в начала:
1) вызов деструктора, а потом копирование protected_variable
2) или же в начале произойдет копирование, потому вызов деструктора.
3) стандарт не гарантирует поведение.

Почти уверен, что второй вариант, но закрались сомнения и не хочу неприятных сюрпризов.
Пример:

int get_var(){
AutoMutex autoX;
autoX.lockread();
return protected_variable;
}

Спасибо.

• Авто Мутексы и return,Вова, 09:15 , 08-Окт-11
  • Авто Мутексы и return,Fx, 13:26 , 08-Окт-11

>[оверквотинг удален]
> 3) стандарт не гарантирует поведение.
> Почти уверен, что второй вариант, но закрались сомнения и не хочу неприятных
> сюрпризов.
> Пример:
> int get_var(){
> AutoMutex autoX;
> autoX.lockread();
> return protected_variable;
> }
> Спасибо.

Оптимизация кода, описанная в 1) явно противоречила бы стандарту с++, если бы protected_variable была типа 'automatic storage duration'.

Подробно тут:
http://stackoverflow.com/questions/2196327/c-destructor-func...

В данном случае, так как protected_variable глобальна, то это условие нарушено. Но, тем не менее, как пишут здесь:

http://stackoverflow.com/questions/5999449/llvm-generating-c...

вначале возвращаемое значение кладётся на стек, затем только выполняются локальные деструкторы.

Почему бы не поднять ваш RAII объект для мутекса на уровень выше? Ведь сейчас, в данном коде, возвращаемое значение в любом случае не будет гарантированно актуальным. Ничто не мешает другому потоку обновить значение глобальной переменной сразу по освобождению мутекса, до присвоения значения, полученного в get_var(). Да вообще, мутекс для одного инта - это перебор, стоит подумать о красивой обертку над чем-то из  http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html
Вообще интересный вопрос, пишите ещё.

>[оверквотинг удален]
>> int get_var(){
>> AutoMutex autoX;
>> autoX.lockread();
>> return protected_variable;
>> }
>> Спасибо.
> Почему бы не поднять ваш RAII объект для мутекса на уровень выше?
> Ведь сейчас, в данном коде, возвращаемое значение в любом случае не
> будет гарантированно актуальным. Ничто не мешает другому потоку обновить значение глобальной
> переменной сразу по освобождению мутекса, до присвоения значения, полученного в get_var().

Спасибо за ответ и за замечание. Хм, еще раз все обдумал, я как раз ушел от уровня выше, потому что get_var() - функция класса, а на уровне выше часто пришлось бы в функциях других классов вызывать через указатель мутекс объекта с которым работаю в данный момент. Показалось не элегантным из-за
1) того что плодяться лишние строки кода, каждый раз приходится блокировать мутекс и думать о нем.
2) можно забыть поставить мутекс (другой пользователь класса забудет, например:) хотя таких нет, но вдруг )
3) излишнее время блокировки мутекса, если переменную возвращаем в какую-нибудь другую функцию LongDurationSearch ( obj.get_var(), xxx); и не использовать промежуточной переменной (излишний код) + мутекс блокирован на время вызова самой функции и возврата из нее)

За все что выше, получается, плачу своим временем реализации функций для каждой переменной: get_var и set_var - что не удобно.

> Да вообще, мутекс для одного инта - это перебор, стоит подумать
> о красивой обертку над чем-то из  http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html

По поводу мутекса для каждого инта - нет, мутекс зачастую один на много однобразных и не очень кретических по времени переменных (AutoMutex надстройка над Mutexом - переменной класса, но вот, как уже писал выше реаоизация get_var и set_var для каждой переменной напрягают маленько)))

И по вопросу актуальности данных, это продумано, если данный взаимосвязаны я использую ручной мутекс на время работы с ними и операциями, а после освобождаю тоже вручную.

За ссылки-обертки Atomic-Builtins.html  спасибо, изучу. Но на первый взгяд ничего не понял, там что-то про интел процессоры только :)