Mutex when returning by value

[Frederick Gotham]

Before I begin, I realise I can just use an atomic_bool but I'm intentionally not for this example.

bool g_is_on;
std::mutex g_mtx_is_on;

bool Is_On(void)
{
std::lock_guard<std::mutex> guard(g_mtx_is_on);

return g_is_on;
}

Is the above code alright? Or do I need an intermediary as so:

bool Is_On(void)
{
std::lock_guard<std::mutex> guard(g_mtx_is_on);

bool const temp = g_is_on;

return temp;
}

[Bo Persson]

The first version is fine. Any destructors are run at the very end of
the scope, after handling any return value. Otherwise returning from
local variables with destructors wouldn't work.

[Bonita Montero]

> bool g_is_on;
> std::mutex g_mtx_is_on;
> bool Is_On(void)
> {
> std::lock_guard<std::mutex> guard(g_mtx_is_on);
> return g_is_on;
> }

For what is this nonsense-code good for ?

[Fred. Zwarts]

Op 22.jul..2020 om 11:52 schreef Frederick Gotham:

Both versions will return the value that g_is_on after locking the
mutex. However, at the moment that the caller inspects the returned
value, g_is_on may have been changed already, because the mutex is
unlocked after determining the return value, but before the caller
proceeds with the next thing. So, in most cases, the mutex is needed in
the caller.

--
Paradoxes in the relation between Creator and creature.
<http://www.wirholt.nl/English>.

[Öö Tiib]

There are no observable difference between what these two examples
of functions do so compiler can generate same code for both.

[Paavo Helde]

22.07.2020 12:52 Frederick Gotham kirjutas:
>
> Before I begin, I realise I can just use an atomic_bool but I'm intentionally not for this example.
>
> bool g_is_on;
> std::mutex g_mtx_is_on;
>
> bool Is_On(void)
> {
> std::lock_guard<std::mutex> guard(g_mtx_is_on);
>
> return g_is_on;
> }
>
> Is the above code alright? Or do I need an intermediary as so:

The above is fine, return value is copied over before releasing the lock.

[Chris M. Thomasson]

I remember a long time ago about something like this. Would the lock be
released before the return value is committed! Its been a while, but
some settled on something like:

<pseudo-code>

bool Is_On(void)
{
bool ret = false;

{
std::lock_guard<std::mutex> guard(g_mtx_is_on);

ret = g_is_on;
}

return ret;
}

[Frederick Gotham]

If I was writing supremely-portable code that I know might make its way to a less-than-perfect compiler, I might do something like this.

I found an alignment error in a PIC compiler a few years ago -- compilers aren't perfect.

[Juha Nieminen]

Frederick Gotham <cauldwel...@gmail.com> wrote:
> If I was writing supremely-portable code that I know might make its way to a less-than-perfect compiler, I might do something like this.
>
> I found an alignment error in a PIC compiler a few years ago -- compilers aren't perfect.

I don't think one should program trying to take into account hypothetical bugs
in some random compiler. That doesn't make much sense.

[David Brown]

No, you'd never get anything written. I once used a compiler (also for
the PIC, which is a seriously brain-dead 8-bit microcontroller) that
could handle structs, and arrays, but not arrays of structs or structs
with arrays in them. You don't write code with such limitations unless
you /really/ need to.

There are occasional non-conformities that are not bugs, but active
choices by compiler manufacturers, and portable code can therefore take
them into consideration if the code needs to run on such systems. TI
has a habit on their microcontroller tools of not zeroing uninitialised
statically allocated data. The justification is that it can mean the
time from microcontroller reset to the start of "main" is too long and
can cause problems with watchdogs. This is nonsense, in my experience,
and this misfeature is the cause of countless problems. Some portable
embedded C code explicitly zero-initialises data in order to avoid
problems if you use it with a TI compiler. (Another non-conforming
"feature" that has a lot more justification is that for small 8-bit
microcontrollers, "double" is often implemented as the same size as
32-bit float.)