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_ENTER();

my_err_code=1;

if( /* ... */ ){

/* result ok */
my_err_code=0;
}

MACRO_THREADS_LEAVE();

/* (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_ENTER();

if( /* ... */ ){

/* result ok */
goto jmp_ok;
}

MACRO_THREADS_LEAVE();
return 1;

jmp_ok:

MACRO_THREADS_LEAVE();
return 0;
}

 

[Richard Bos]

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_ENTER();

if( /* ... */ ){

/* result ok */
goto jmp_ok;
}

MACRO_THREADS_LEAVE();
return 1;

jmp_ok:

MACRO_THREADS_LEAVE();
return 0;
}

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]

normally I use a local variable assigned to different return values
inside the function and return it like this: [snip]
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?

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.programming.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]

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

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.

(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?

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

Lawrence