What is multithread safety

[Shalini Joshi]

Hi, I was trying to find out what exactly is meant by multi-thread
safe code/functions etc. I couldn't find relevant information on the
web and would appreciate any useful links/information on this topic.

Thanks.

Sincerely,
Shalini.

 

[Dave Vandervies]

Hi, I was trying to find out what exactly is meant by multi-thread
safe code/functions etc. I couldn't find relevant information on the
web and would appreciate any useful links/information on this topic.

This refers to code that is still correct if multiple threads are running
it concurrently.
This is beyond the scope of the C language and therefore not appropriate
for comp.lang.c .

Googling for `thread safety' turns up a few sensible hits (how hard did
you actually try to `find relevant information on the web'?).

comp.programming.threads is probably the best place to ask questions.


dave

 

[Kelsey Bjarnason]

Hi, I was trying to find out what exactly is meant by multi-thread
safe code/functions etc. I couldn't find relevant information on the
web and would appreciate any useful links/information on this topic.

Fundamentally, it's simply off-topic here, as C doesn't have threading
support. However, the idea is simple enough: ask yourself what would
happen if two different threads accessed or modified the same piece of
data in an unpredictable manner. As an example:

/* file.c */
static char workbuff[32];

void myfunc( char *s )
{
/* do something with workbuff */
strcpy( s, workbuff );
}


If there's only one thread, myfunc will operate correctly. But suppose
there are two threads, and half way through "do something", the second
thread calls myfunc. The second thread "does something" which overwrites
whatever is in workbuff, so when control goes back to the first function,
the buffer is not what it should be. Thus the function is not thread safe.

To make it thread safe, you could do many things. Allocate workbuff on
the fly. Use thread-local storage. Use an automatic buffer. Create a
lock so that two processes can never modify the buffer at the same time.

What you can't do is allow more than one thread to modify the _same_
variable without some form of protection.

 

[Malcolm]

Hi, I was trying to find out what exactly is meant by multi-thread
safe code/functions etc. I couldn't find relevant information on the
web and would appreciate any useful links/information on this topic.

To all intents and purposes, thread safety in C means avoiding global and
static variables.

 

[Thomas Stegen]

To all intents and purposes, thread safety in C means avoiding global and
static variables.

That does not guarantee thread safety. A thread safe ISO C program will
not use pointers except in certain ways, will not use dynamically
allocated memory except in certain ways and will not use, as you said,
variables with extent that does not follow scope.

I think that might be enough...

 

[E. Robert Tisdale]

Hi, I was trying to find out
what exactly is meant by multi-thread safe code/functions etc.
I couldn't find relevant information on the web
and would appreciate any useful links/information on this topic.

Code is "thread safe"
1.) if multiple threads cannot modify shared program state variables or
2.) shared program state variables are protected by "mutual exclusion".

The term "thread safe" actually refers to the first property.
Codes (C functions/programs) which rely on mutual exclusion,
either explicitly or implicitly,
are more properly described as *threaded* functions/programs.

 

[=?iso-8859-1?q?Nils_O=2E_Sel=E5sdal?=]

To all intents and purposes, thread safety in C means avoiding global and
static variables.

You mean there is no program where multiple threads access non global
data ?
For all intents and purposes, your comment is completely nonsense.

 

[=?iso-8859-1?q?Nils_O=2E_Sel=E5sdal?=]

You mean there is no program where multiple threads access non global
data ?
For all intents and purposes, your comment is completely nonsense.

Well, atleast for things outside standard C which DO support
multi threading.

 

[E. Robert Tisdale]

You mean
there is no program where multiple threads access non global data?

No.
He means that there are no thread safe *functions*
which access non global data.
Functions which access global data must actually be threaded --
they must use a thread library which guarantees "mutual exclusion"
while they are modifying the global variables
and/or they must use threaded library functions
which use mutual exclusion when modifying global variables.

 

[Eric Sosman]

Nils O. Selåsdal wrote:



No.
He means that there are no thread safe *functions*
which access non global data.

I doubt that's what he means. For example, it
would imply that a thread-safe function could not
access its own arguments or its own `auto' and
`register' variables.

 

[Shalini Joshi]

Thanks a lot Kelsey, Dave for explaining it. I actually came across
the term while reading up on how to write secure functions in C - and
wondered what it meant. I am sorry i should have searched harder on
the web ( was actually searching for "multithread safe functions" so
now I know why i was getting Java-related stuff mostly).

Regards,

Shalini.

 

[Herbert Rosenau]

No.
He means that there are no thread safe *functions*
which access non global data.
Functions which access global data must actually be threaded --
they must use a thread library which guarantees "mutual exclusion"
while they are modifying the global variables
and/or they must use threaded library functions
which use mutual exclusion when modifying global variables.

I'm writing multithreaded applications and libraries since 1988. No,
not the flaky linux threading. Real, kernel based threading. I have
written thousends of functions handling global data, handling static
data, sending pointers around from thread to thread, receiving
pointers in multiwindow, multiproces, multithreaded applications
flawless.

Having multithreading that handles threads better than linux handles
processes makes it much easier to control the flow as you would know
that any of your thread can be interrupted by another thread even
while it is insinde a single C instruction.

Having an OS that gives you many varied APIs to get that under control
makes it really easy. Have the chance to block thread change for
limited time in a single process, variant types of semaphores and
other technics to control the program flow makes it easy to spread new
threads, block access to variables, block access to code, to devices,
to shared memory and so on makes interthread and interprocess
communication easy.

Letting the OS handle not only process but thread scheduling gives you
more control about threads as pthreads ever can reach. Sure, you needs
a thread aware standard C library - but any C compiler can deliver it.
No need to waste one single second on that other than to define the
right linker flags for that. Select the right blocking mechanism and
you can acces global and static variables and even use nonreentrant
functions in your multithreaded environment.

 

[E. Robert Tisdale]

Should be:

which access global data.

I doubt that's what he means. For example, it
would imply that a thread-safe function could not
access its own arguments or its own `auto' and
`register' variables.

 

[Herbert Rosenau]

Code is "thread safe"
1.) if multiple threads cannot modify shared program state variables or

Wrong on OSes that are capapable of preemtive multithreading on single
and multi CPU computers.

2.) shared program state variables are protected by "mutual exclusion".

Wrong too.

The term "thread safe" actually refers to the first property.
Codes (C functions/programs) which rely on mutual exclusion,
either explicitly or implicitly,
are more properly described as *threaded* functions/programs.

Not true.

Having an OS that does handle multithreading on kernel level, having
the right methods of controlling threads - and semaphores are an
relative seldom needed way on that. Half hearted pthreads are only a
dumb compromise between multiprocessing, and real preemtive
multithreading.

I've written multithreaded applications and libraries without any use
of semaphores but handling lots of global and shared data using other,
quite simpler methods to coordinate access to them.

 

[Randy Howard]

To all intents and purposes, thread safety in C means avoiding global and
static variables.

Not hardly. Hence not answering OT questions being a good idea.

 

[Dan Pop]

To all intents and purposes, thread safety in C means avoiding global and
static variables.

It also means avoiding *any* library function:

4 The functions in the standard library are not guaranteed to be
reentrant and may modify objects with static storage duration.

Dan

 

[E. Robert Tisdale]

Not hardly.
Wrong!

Hence not answering OT questions being a good idea.

Correct.

 

[CBFalconer]

It also means avoiding *any* library function:

4 The functions in the standard library are not guaranteed to be
reentrant and may modify objects with static storage duration.

Qualify that. function of which you do not have the full source
(right down to the hardware) and the capability of evaluating.

Of course higher quality libraries and systems guard their critical
sections. This allows you to treat things that call them as if
they were re-entrant.

 

[Malcolm]

It also means avoiding *any* library function:

4 The functions in the standard library are not guaranteed to be
reentrant and may modify objects with static storage duration.

There are other issues. The basic problem is that two threads might access
the same variable at the same time, for instance a global integer may be
half written and then accessed by the second thread, causing a garbage read.
Or the algorithm could rely on the value remaining constant for the duration
of the function, when in fact it changes.
However you can also have contention for hardware resources, and I can
easily believe that standard library functions are not guaranteed to be
reentrant (some, like strtok(), are difficult to write in a thread-safe
manner). So I am not giving a complete guide to implementing thread-safe C,
just explaining the basic issue.

 

[Randy Howard]

Wrong!

ERT, If you think that's all there is to doing it properly, you've got
even more to learn about that than you do about C.