By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,804 Members | 1,666 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,804 IT Pros & Developers. It's quick & easy.

std::auto_ptr and Unwind Order?

P: n/a
Hello,

I am trying to write some threadsafe code. I am using mutexes to restrict
access to certain class members. Consider the method below:

// begin code nippet

bool rControl::getVisibility() {

{

std::auto_ptr<rMutexAccess> mutexAccess(new
rMutexAccess(this->objectMutex));

// get visibility

return visible;

}

}

// end code nippet

So, basically, I am creating the mutex using an auto_ptr to give myself a
guarantee that the mutex will unlock (it unlocks on destruction of the
rMutexAccess) no matter what happens in the code.

My question is this: in the above code, which happens first? A) Does the
member "visible" get copied to be returned, after which the mutex destructs,
or B) The mutex destructs, and then the member "visible" get copied to be
returned.

Can you see what I am getting at? In normal code it is fine, I can see
clearly what will happen, but with a "return" statement inside the protected
nest { ... } I am not sure what happens.

Thanks!

Jamie Burns.
Jul 19 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
"Jamie Burns" <se*****@email.com> wrote in message
news:bo*******************@news.demon.co.uk...
Hi Jamie,
....
| // begin code nippet
|
| bool rControl::getVisibility() {
|
| {
|
| std::auto_ptr<rMutexAccess> mutexAccess(new
| rMutexAccess(this->objectMutex));
|
| // get visibility
|
| return visible;
|
| }
|
| }
|
| // end code nippet
|
| So, basically, I am creating the mutex using an auto_ptr to give myself a
| guarantee that the mutex will unlock (it unlocks on destruction of the
| rMutexAccess) no matter what happens in the code.

First of all, note that it is unnecessary to use an auto_ptr here.
You can simply rely on an automatic (stack-based) variable:
{
rMutexAccess mutexAccess(this->objectMutex);
return visible;
}

| My question is this: in the above code, which happens first? A) Does the
| member "visible" get copied to be returned, after which the mutex
destructs,
| or B) The mutex destructs, and then the member "visible" get copied to be
| returned.

The returned expression is first evaluated and copied as the
function's result value. Then the function scopes are exited,
and all the stack based objects will be destroyed.
[at least that's my reading of the standard, 6.6,
but this is what happens in practice if you try to test it]

So your code snipped is ok, although I think it has to be simplified...
hth-Ivan
--
http://ivan.vecerina.com
Jul 19 '05 #2

P: n/a
Thanks Ivan!

Of course I don't need auto_ptr! Silly me!

Good to know the variable copy comes first...

Jamie.

"Ivan Vecerina" <pl*****************@ivan.vecerina.com> wrote in message
news:bo**********@newshispeed.ch...
"Jamie Burns" <se*****@email.com> wrote in message
news:bo*******************@news.demon.co.uk...
Hi Jamie,
...
| // begin code nippet
|
| bool rControl::getVisibility() {
|
| {
|
| std::auto_ptr<rMutexAccess> mutexAccess(new
| rMutexAccess(this->objectMutex));
|
| // get visibility
|
| return visible;
|
| }
|
| }
|
| // end code nippet
|
| So, basically, I am creating the mutex using an auto_ptr to give myself a | guarantee that the mutex will unlock (it unlocks on destruction of the
| rMutexAccess) no matter what happens in the code.

First of all, note that it is unnecessary to use an auto_ptr here.
You can simply rely on an automatic (stack-based) variable:
{
rMutexAccess mutexAccess(this->objectMutex);
return visible;
}

| My question is this: in the above code, which happens first? A) Does the
| member "visible" get copied to be returned, after which the mutex
destructs,
| or B) The mutex destructs, and then the member "visible" get copied to be | returned.

The returned expression is first evaluated and copied as the
function's result value. Then the function scopes are exited,
and all the stack based objects will be destroyed.
[at least that's my reading of the standard, 6.6,
but this is what happens in practice if you try to test it]

So your code snipped is ok, although I think it has to be simplified...
hth-Ivan
--
http://ivan.vecerina.com

Jul 19 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.