Re: Dead Lock in singe threaded application

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article <20011003035125.A29000@alinoe.com> you write:

> Hi, I did run into a dead lock with a single threaded application
> and was wondering if the standard allows this dead lock or not.

Since the standard does not refer to threads, deadlocks relating to an
implementation that supports them are a quality of implementation
issue.  Depending on how/if you abused library code, we could point
the finger at the standard C++ library implementation.

> The problem is most likely the fact that I am writing a C++
> debugging library who uses 'string' and which redefines its
> own malloc function.

You answer your own question.  Looking at the back trace you provided
confirms it in my mind.  Strictly speaking: it is not because you
redefine malloc(), it is because your redefinition of malloc() uses
the C++ library which itself uses malloc().

> I could start to use my own allocator<> :/, but I am worried
> about this: I had to drop support for Multi-Threading for
> per-3.0 because of a similar problem.  If more dead locks
> like this are latent then in the end I'd not be allowed to
> use libstdc++ at all in my library - which would be impossible
> given the current state.

Due to the fact that the C++ library depends upon the C library
implementation, please don't use C++ library calls in malloc()
replacement implementation.  You have introduced what I fondly call a
recursive library dependency problem.  You should find life more
simple if you always strictly layer your library code.  You should
never be able to find a cycle where A implements B and B implements A.
There might be any number of function calls between A and B.

I tend to think this is what you have done.

Does the C++ standard say you can replace malloc()?  (Even if not,
most C hackers expect that they can do so, thus as a QoI issue, most
UNIX C libraries have allowed this over the years.)  Does it say you
can replace malloc() with one that uses functions that they themselves
might use malloc()?  I dare say that no matter what the standard says
about being able to replace a function, it surely doesn't cover the
second question in a manner that makes me believe that you have not
abused the library implementation.

> Here is the back trace of the dead lock.

Regards,
Loren
-- 
Loren J. Rittle
Senior Staff Software Engineer, Distributed Object Technology Lab
Networks and Infrastructure Research Lab (IL02/2240), Motorola Labs
rittle@rsch.comm.mot.com, KeyID: 2048/ADCE34A5, FDC0292446937F2A240BC07D42763672