[omniORB] omni_semaphore->post() lockup on Mac OS X

[Mike Richmond]

We are seeing an occassional lockup in omni_semaphore::post() when 
running omniORB 3.0.4 on Mac OS X.  Looking at the code for 
omni_semaphore::post() we suspect that that is where the problem is. 
Mac OS X uses POSIX threads, so omni_semaphore::post() is:

   void
   omni_semaphore::post(void)
   {
     {
         omni_mutex_lock l(m);
         value++;
     }

     c.signal();
   }

We have "fixed" the lockup by moving the c.signal() call inside the 
synchronised block:

   void
   omni_semaphore::post(void)
   {
     omni_mutex_lock l(m);
     value++;
     c.signal();
   }

This then matches the implementation in mach.cc and typical pthread 
sample code in the books.

Code to illustrate our problem requires a "processing" thread and a 
"waiting" thread.  The "processing" thread is:

   gGlobalSemaphore->wait();  // Wait for waiting thread to post an action

   {
     omni_mutex_lock l(gMutex);
     semaphore = ...;         // In effect, remove semaphore from queue
   }

   doStuff();
   semaphore->post();        // Signal completion to waiting thread

The "waiting" thread is:

   omni_semaphore * semaphore = new omni_semaphore(0);

   {
     omni_mutex_lock l(gMutex);
     ... = semaphore;         // In effect, add semaphore to queue
   }

   gGlobalSemaphore->post();  // Wake up processing thread
   semaphore->wait();         // Wait for processing thread to do its stuff
   delete semaphore;          // trash semaphore

When semaphore->post() locks up semaphore is pointing to garbage 
values.  We suspect that the memory for semaphore has been reused 
after the waiting thread has deleted the semaphore object.  An 
example gdb backtrace for the locked-up "processing" thread is:

   Thread 2 (process 5792 thread 0x1303):
   #0  0x90014d08 in syscall_thread_switch ()
   #1  0x900140bc in pthread_cond_signal_thread_np ()
   #2  0x0005bf20 in omni_condition::signal ()
   #3  0x0005c164 in omni_semaphore::post ()
   #4  0x00002940 in processingFn ()
   #5  0x0005c348 in omni_thread_wrapper ()
   #6  0x90020d28 in _pthread_body ()

Have we missed something, or should omni_semaphore::post() be changed 
as we suggest?

Mike Richmond
Global Graphics Software Ltd