Subj : Re: deadlock avoidance
To   : comp.programming.threads
From : Giancarlo Niccolai
Date : Thu Jul 07 2005 12:55 pm

Dijkstra wrote:

> Hi there!
> 
> The Giancarlo article is right: A C function using a global or static
> variable is surely not reentrant. It may be reentrant if you take great
> care not to use this variable simultaneously, which will lead you to
> use some kind of syncronization, killing reentrancy to a great extent.
> 

Thank you for your support; 

I reply "phisically" to you but my intention is to reply also to former (and
latter) messages.

First of all, a non reentrant function may be threadsafe, this is of course
true (or it wouldn't exist any multithreading at all), but... that sentence
just explains that if a function manipulates shared or static data, then
it's not reentrant. Reentrant functions presents themselves in the same
state, you may name it "initial", at every call, be it called from just one
thread or be it concurrently called for several threads; if they need status
memory, they provide a mechanism to store this status in the parameters. If
a function needs to use global or static variables, then it is very
probably doing that to keep  track or alter the state (if not, then it is
anyhow doing something with the state, even if its not not willing to). 

So, my point is that IF every "low level function", "library function", or
in general any function that doesn't know how to interact with your
program's threading model (by design) is reentrant THEN your program CAN be
threadsafe. Of course, you can use non reentrant low level functions in
threaded program and make their access threadsafe, but see below:

> I also agree to the sentence "Every access to shared data must be
> guarded with a mutex". It is true, period. You can not assure a C
> sentence is atomic enough, not even a simple assignment -- think of
> other architectures, not only x86. If you take this to C++, I can count
> many cases where "a = b" may take hundred lines of micro-code.
> 

This is the key point. In an introductory article, it is better IMHO to tell
what's the Right Thing (TM) and possibly avoid EVEN to mention any
"exception" to the "right thing" rules. Exceptions are countless, and they
will confuse the inexperienced reader that is going to form it's first
opinion of a topic (i.e. MT) based on that reading. So, when the reader has
reached a level named "Know What You Are Doing" (TM), it is then possible
to hint some exception, but probably it won't be necessary, as the Know
What You Are Doing experienced reader will be able to know and exploit
exceptions by itself.

As what Miguel said holds true, that is, as
there is no guarantee that C compiler treats even simple assignments as
atomic operations, it is evident that the other posters have been
influenced by exception-revealing readings before they reached the Know
What You Are Doing level, and this confirms my pedagogic theory.

Until you Know What You Are Doing, please stick to my suggestion to always
lock shared resources access, or your programs cannot be guaranteed to be
threadsafe everywhere. 

This applies also to "make safe the non-reentrant low-level functions"
problem; there are many implications I won't write of here, and that
couldn't ever possibly find space in an introductory article, so the rule,
until you Know What You Are Doing, is "DON'T". Either put in your program
only reentrant library functions, or deeply study the specific topic and
how it can be safely solved. 

PS: I see some interest on the topic at last, so I have decided to translate
the other three articles that I have published on the topic ASAP, that
should probably be something around next weekend.

Bests,
Giancarlo Niccolai.

.