
deadlock_detection_test

deadlock_detection_test is an insane program.  Basically, it spawns two
threads which attempt to deadlock.  Logically, there are two tokens A
and B.  Here is what both threads try to do:

Thread 1		Thread 2
--------		--------
Repeat 100 times	Repeat 100 times
  acquire A		  acquire B
  acquire B		  acquire A
  release A and B	  release A and B
repeat			repeat

Notice that A and B are reversed in 1 and 2.  If the token manager
(which is not in the public interface, but hidden behind
ACE_Local_Mutex) works properly, they should detect the deadlock.  If
a thread detects deadlock, the resources held are released, and it
starts the whole process over again.

What can be confusing about the test program is all the other tricks
I'm pulling to test other aspects of the library.  For instance, I'm
using both "global" and "local" ACE_Local_Mutexes.  This is to test
the ability to have multiple threads using one token proxy as well as
multiple threads each using their own proxies.  All the while, the
same logical token is being used.  If this doesn't make sense, don't
worry about it.  Just use the ACE_Local_Mutex any way you want.

Another confusing trick is that I'm testing recursive acquisition.
(Two acquires in a row.)  I have to make sure that the token manager
doesn't detect a recursive acquire as deadlock.

To run a test, simply type:
% ./deadlock_detection_test

This should run 100 times through the above pseudo code.  If the
application halts, then we have trouble.  It should never ever halt.
I've included a little flag with the ACE_Local_Mutex class to allow
deadlock detection to be ignored.  So, if you run the test as follows,
deadlock detection will be ignored.

% ./deadlock_detection_test blah

In this case, the application should only run about a second before
deadlock occurs and the application halts.  
