Subj : Re: deadlock avoidance
To   : comp.programming.threads
From : Giancarlo Niccolai
Date : Wed Jul 06 2005 04:11 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
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 you need to use
global or static variables, then you are very probably doing that to keep
track or alter the state of the function (if not, then you are anyhow doing
something with the state of the function, even if you are not willing to). 

So, my point is that 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) must be reentrat for the program to be
threadsafe. 

Of course, you can use non reentrant 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 introductry article, it is better IMHO to tell
what's the Right Thing (TM) and possibily 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 Dijkstra (I suppose it's a nickname?) 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.

.