return const value to be thread save?

[Felix Kater]

Hi,

normally I use a local variable assigned to different return values inside the function and return it like this:


[example 1:]

int f(){
int my_err_code;
my_err_code=1;

if( /* ... */ ){

/* result ok */
my_err_code=0;
}

return my_err_code;
}


If I now add two macros to make the function thread save (assume they
work properly) isn't there still a slight chance that the return
variable is changed by a second thread just before the first thread
leaves the function?


[example 2:]

int f(){
int my_err_code;

MACRO_THREADS_E NTER();

my_err_code=1;

if( /* ... */ ){

/* result ok */
my_err_code=0;
}

MACRO_THREADS_L EAVE();

/* (Couldn't the second thread NOW have already changed
my_err_code=1 ? */

return my_err_code;
}


So, I wonder if it is necessary to return constant values to be thread
save in functions and code the fucntion like this:


[example 3:]

int f(){

MACRO_THREADS_E NTER();

if( /* ... */ ){

/* result ok */
goto jmp_ok;
}

MACRO_THREADS_L EAVE();
return 1;

jmp_ok:

MACRO_THREADS_L EAVE();
return 0;
}

[Richard Bos]

Re: return const value to be thread save?

Felix Kater <f.kater2@gmx.n et> wrote:
[color=blue]
> So, I wonder if it is necessary to return constant values to be thread
> save in functions and code the fucntion like this:
>
>
> [example 3:]
>
> int f(){
>
> MACRO_THREADS_E NTER();
>
> if( /* ... */ ){
>
> /* result ok */
> goto jmp_ok;
> }
>
> MACRO_THREADS_L EAVE();
> return 1;
>
> jmp_ok:
>
> MACRO_THREADS_L EAVE();
> return 0;
> }[/color]

I have no answer to your threads question, except to note that threads
are not ISO C, and therefore off-topic here. You might have better
results asking in a newsgroup that deals with the particular threads
library you're using. This is a good idea anyway, since I can easily
imagine different species of threads requiring different answers to your
original question.
However, I'd like to note that if you're going to use goto like that,
you've already cast Wirthian rigor to the wind (with good reason), and
might as well put the return statement where you now have the goto.

Richard

[Alex Fraser]

Re: return const value to be thread save?

"Felix Kater" <f.kater2@gmx.n et> wrote in message
news:2005050308 2941.4b77158c.f .kater2@gmx.net ...[color=blue]
> normally I use a local variable assigned to different return values
> inside the function and return it like this:[/color]
[snip][color=blue]
> If I now add two macros to make the function thread save (assume they
> work properly) isn't there still a slight chance that the return
> variable is changed by a second thread just before the first thread
> leaves the function?[/color]

Threads are not part of standard C, so your question is off-topic here. You
should ask in a group dedicated to your platform or perhaps
comp.programmin g.threads.

That said, the answer is almost certainly no; if you have two threads
running a function, there will be two seperate areas for storing the
function's automatic variables (typically each thread's stack, or processor
registers).

Alex

[Lawrence Kirby]

Re: return const value to be thread save?

On Tue, 03 May 2005 08:29:41 +0200, Felix Kater wrote:
[color=blue]
> Hi,
>
> normally I use a local variable assigned to different return values inside the function and return it like this:
>
>
> [example 1:]
>
> int f(){
> int my_err_code;
> my_err_code=1;
>
> if( /* ... */ ){
>
> /* result ok */
> my_err_code=0;
> }
>
> return my_err_code;
> }
>
>
> If I now add two macros to make the function thread save[/color]

Standard C doesn't support threads as such but similar situations can
arise in signal handling. Problems only occur when 2 "threads" (including
signal handlers) could access the same object in memory. Each invocation
of a function gets its own set of automatic variables so this isn't an
issue, i.e. the code we can see above is already thread safe in any
reasonable implementation of threads.
[color=blue]
> (assume they
> work properly) isn't there still a slight chance that the return
> variable is changed by a second thread just before the first thread
> leaves the function?[/color]

Two invocations of the function would have separate returns accessing
separate areas of memory.

Lawrence