RubyGems - noderb - Versions diffs - 0.0.4 → 0.0.6 - Mend

noderb 0.0.4 → 0.0.6

Files changed (361) hide show

data/ext/noderb_extension/libuv/deps/pthread-win32/README.CV DELETED Viewed

@@ -1,3036 +0,0 @@
-README.CV -- Condition Variables
---------------------------------
-The original implementation of condition variables in
-pthreads-win32 was based on a discussion paper:
-"Strategies for Implementing POSIX Condition Variables
-on Win32": http://www.cs.wustl.edu/~schmidt/win32-cv-1.html
-The changes suggested below were made on Feb 6 2001. This
-file is included in the package for the benefit of anyone
-interested in understanding the pthreads-win32 implementation
-of condition variables and the (sometimes subtle) issues that
-it attempts to resolve.
-Thanks go to the individuals whose names appear throughout
-the following text.
-Ross Johnson
---------------------------------------------------------------------
-fyi.. (more detailed problem description/demos + possible fix/patch)
-regards,
-alexander.
-Alexander Terekhov
-31.01.2001 17:43
-To:   ace-bugs@cs.wustl.edu
-cc:
-From: Alexander Terekhov/Germany/IBM@IBMDE
-Subject:  Implementation of POSIX CVs: spur.wakeups/lost
-      signals/deadlocks/unfairness
-    ACE VERSION:
-        5.1.12 (pthread-win32 snapshot 2000-12-29)
-    HOST MACHINE and OPERATING SYSTEM:
-        IBM IntelliStation Z Pro, 2 x XEON 1GHz, Win2K
-    TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
-    COMPILER NAME AND VERSION (AND PATCHLEVEL):
-        Microsoft Visual C++ 6.0
-    AREA/CLASS/EXAMPLE AFFECTED:
-        Implementation of POSIX condition variables - OS.cpp/.h
-    DOES THE PROBLEM AFFECT:
-        EXECUTION? YES!
-    SYNOPSIS:
-        a) spurious wakeups (minor problem)
-        b) lost signals
-        c) broadcast deadlock
-        d) unfairness (minor problem)
-    DESCRIPTION:
-        Please see attached copy of discussion thread
-        from comp.programming.threads for more details on
-        some reported problems. (i've also posted a "fyi"
-        message to ace-users a week or two ago but
-        unfortunately did not get any response so far).
-        It seems that current implementation suffers from
-        two essential problems:
-        1) cond.waiters_count does not accurately reflect
-           number of waiters blocked on semaphore - w/o
-           proper synchronisation that could result (in the
-           time window when counter is not accurate)
-           in spurious wakeups organised by subsequent
-           _signals  and _broadcasts.
-        2) Always having (with no e.g. copy_and_clear/..)
-           the same queue in use (semaphore+counter)
-           neither signal nor broadcast provide 'atomic'
-           behaviour with respect to other threads/subsequent
-           calls to signal/broadcast/wait.
-        Each problem and combination of both could produce
-        various nasty things:
-        a) spurious wakeups (minor problem)
-             it is possible that waiter(s) which was already
-             unblocked even so is still counted as blocked
-             waiter. signal and broadcast will release
-             semaphore which will produce a spurious wakeup
-             for a 'real' waiter coming later.
-        b) lost signals
-             signalling thread ends up consuming its own
-             signal. please see demo/discussion below.
-        c) broadcast deadlock
-             last_waiter processing code does not correctly
-             handle the case with multiple threads
-             waiting for the end of broadcast.
-             please see demo/discussion below.
-        d) unfairness (minor problem)
-             without SignalObjectAndWait some waiter(s)
-             may end up consuming broadcasted signals
-             multiple times (spurious wakeups) because waiter
-             thread(s) can be preempted before they call
-             semaphore wait (but after count++ and mtx.unlock).
-    REPEAT BY:
-        See below... run problem demos programs (tennis.cpp and
-        tennisb.cpp) number of times concurrently (on multiprocessor)
-        and in multiple sessions or just add a couple of "Sleep"s
-        as described in the attached copy of discussion thread
-        from comp.programming.threads
-    SAMPLE FIX/WORKAROUND:
-        See attached patch to pthread-win32.. well, I can not
-        claim that it is completely bug free but at least my
-        test and tests provided by pthreads-win32 seem to work.
-        Perhaps that will help.
-        regards,
-        alexander.
->> Forum: comp.programming.threads
->> Thread: pthread_cond_* implementation questions
-.
-.
-.
-David Schwartz <davids@webmaster.com> wrote:
-> terekhov@my-deja.com wrote:
->
->> BTW, could you please also share your view on other perceived
->> "problems" such as nested broadcast deadlock, spurious wakeups
->> and (the latest one) lost signals??
->
->I'm not sure what you mean. The standard allows an implementation
->to do almost whatever it likes. In fact, you could implement
->pthread_cond_wait by releasing the mutex, sleeping a random
->amount of time, and then reacquiring the mutex. Of course,
->this would be a pretty poor implementation, but any code that
->didn't work under that implementation wouldn't be strictly
->compliant.
-The implementation you suggested is indeed correct
-one (yes, now I see it :). However it requires from
-signal/broadcast nothing more than to "{ return 0; }"
-That is not the case for pthread-win32 and ACE
-implementations. I do think that these implementations
-(basically the same implementation) have some serious
-problems with wait/signal/broadcast calls. I am looking
-for help to clarify whether these problems are real
-or not. I think that I can demonstrate what I mean
-using one or two small sample programs.
-.
-.
-.
-==========
-tennis.cpp
-==========
-#include "ace/Synch.h"
-#include "ace/Thread.h"
-enum GAME_STATE {
-  START_GAME,
-  PLAYER_A,     // Player A playes the ball
-  PLAYER_B,     // Player B playes the ball
-  GAME_OVER,
-  ONE_PLAYER_GONE,
-  BOTH_PLAYERS_GONE
-};
-enum GAME_STATE             eGameState;
-ACE_Mutex*                  pmtxGameStateLock;
-ACE_Condition< ACE_Mutex >* pcndGameStateChange;
-void*
-  playerA(
-    void* pParm
-  )
-{
-  // For access to game state variable
-  pmtxGameStateLock->acquire();
-  // Play loop
-  while ( eGameState < GAME_OVER ) {
-    // Play the ball
-    cout << endl << "PLAYER-A" << endl;
-    // Now its PLAYER-B's turn
-    eGameState = PLAYER_B;
-    // Signal to PLAYER-B that now it is his turn
-    pcndGameStateChange->signal();
-    // Wait until PLAYER-B finishes playing the ball
-    do {
-      pcndGameStateChange->wait();
-      if ( PLAYER_B == eGameState )
-        cout << endl << "----PLAYER-A: SPURIOUS WAKEUP!!!" << endl;
-    } while ( PLAYER_B == eGameState );
-  }
-  // PLAYER-A gone
-  eGameState = (GAME_STATE)(eGameState+1);
-  cout << endl << "PLAYER-A GONE" << endl;
-  // No more access to state variable needed
-  pmtxGameStateLock->release();
-  // Signal PLAYER-A gone event
-  pcndGameStateChange->broadcast();
-  return 0;
-}
-void*
-  playerB(
-    void* pParm
-  )
-{
-  // For access to game state variable
-  pmtxGameStateLock->acquire();
-  // Play loop
-  while ( eGameState < GAME_OVER ) {
-    // Play the ball
-    cout << endl << "PLAYER-B" << endl;
-    // Now its PLAYER-A's turn
-    eGameState = PLAYER_A;
-    // Signal to PLAYER-A that now it is his turn
-    pcndGameStateChange->signal();
-    // Wait until PLAYER-A finishes playing the ball
-    do {
-      pcndGameStateChange->wait();
-      if ( PLAYER_A == eGameState )
-        cout << endl << "----PLAYER-B: SPURIOUS WAKEUP!!!" << endl;
-    } while ( PLAYER_A == eGameState );
-  }
-  // PLAYER-B gone
-  eGameState = (GAME_STATE)(eGameState+1);
-  cout << endl << "PLAYER-B GONE" << endl;
-  // No more access to state variable needed
-  pmtxGameStateLock->release();
-  // Signal PLAYER-B gone event
-  pcndGameStateChange->broadcast();
-  return 0;
-}
-int
-main (int, ACE_TCHAR *[])
-{
-  pmtxGameStateLock   = new ACE_Mutex();
-  pcndGameStateChange = new ACE_Condition< ACE_Mutex >( *pmtxGameStateLock
-);
-  // Set initial state
-  eGameState = START_GAME;
-  // Create players
-  ACE_Thread::spawn( playerA );
-  ACE_Thread::spawn( playerB );
-  // Give them 5 sec. to play
-  Sleep( 5000 );//sleep( 5 );
-  // Set game over state
-  pmtxGameStateLock->acquire();
-  eGameState = GAME_OVER;
-  // Let them know
-  pcndGameStateChange->broadcast();
-  // Wait for players to stop
-  do {
-    pcndGameStateChange->wait();
-  } while ( eGameState < BOTH_PLAYERS_GONE );
-  // Cleanup
-  cout << endl << "GAME OVER" << endl;
-  pmtxGameStateLock->release();
-  delete pcndGameStateChange;
-  delete pmtxGameStateLock;
-  return 0;
-}
-===========
-tennisb.cpp
-===========
-#include "ace/Synch.h"
-#include "ace/Thread.h"
-enum GAME_STATE {
-  START_GAME,
-  PLAYER_A,     // Player A playes the ball
-  PLAYER_B,     // Player B playes the ball
-  GAME_OVER,
-  ONE_PLAYER_GONE,
-  BOTH_PLAYERS_GONE
-};
-enum GAME_STATE             eGameState;
-ACE_Mutex*                  pmtxGameStateLock;
-ACE_Condition< ACE_Mutex >* pcndGameStateChange;
-void*
-  playerA(
-    void* pParm
-  )
-{
-  // For access to game state variable
-  pmtxGameStateLock->acquire();
-  // Play loop
-  while ( eGameState < GAME_OVER ) {
-    // Play the ball
-    cout << endl << "PLAYER-A" << endl;
-    // Now its PLAYER-B's turn
-    eGameState = PLAYER_B;
-    // Signal to PLAYER-B that now it is his turn
-    pcndGameStateChange->broadcast();
-    // Wait until PLAYER-B finishes playing the ball
-    do {
-      pcndGameStateChange->wait();
-      if ( PLAYER_B == eGameState )
-        cout << endl << "----PLAYER-A: SPURIOUS WAKEUP!!!" << endl;
-    } while ( PLAYER_B == eGameState );
-  }
-  // PLAYER-A gone
-  eGameState = (GAME_STATE)(eGameState+1);
-  cout << endl << "PLAYER-A GONE" << endl;
-  // No more access to state variable needed
-  pmtxGameStateLock->release();
-  // Signal PLAYER-A gone event
-  pcndGameStateChange->broadcast();
-  return 0;
-}
-void*
-  playerB(
-    void* pParm
-  )
-{
-  // For access to game state variable
-  pmtxGameStateLock->acquire();
-  // Play loop
-  while ( eGameState < GAME_OVER ) {
-    // Play the ball
-    cout << endl << "PLAYER-B" << endl;
-    // Now its PLAYER-A's turn
-    eGameState = PLAYER_A;
-    // Signal to PLAYER-A that now it is his turn
-    pcndGameStateChange->broadcast();
-    // Wait until PLAYER-A finishes playing the ball
-    do {
-      pcndGameStateChange->wait();
-      if ( PLAYER_A == eGameState )
-        cout << endl << "----PLAYER-B: SPURIOUS WAKEUP!!!" << endl;
-    } while ( PLAYER_A == eGameState );
-  }
-  // PLAYER-B gone
-  eGameState = (GAME_STATE)(eGameState+1);
-  cout << endl << "PLAYER-B GONE" << endl;
-  // No more access to state variable needed
-  pmtxGameStateLock->release();
-  // Signal PLAYER-B gone event
-  pcndGameStateChange->broadcast();
-  return 0;
-}
-int
-main (int, ACE_TCHAR *[])
-{
-  pmtxGameStateLock   = new ACE_Mutex();
-  pcndGameStateChange = new ACE_Condition< ACE_Mutex >( *pmtxGameStateLock
-);
-  // Set initial state
-  eGameState = START_GAME;
-  // Create players
-  ACE_Thread::spawn( playerA );
-  ACE_Thread::spawn( playerB );
-  // Give them 5 sec. to play
-  Sleep( 5000 );//sleep( 5 );
-  // Make some noise
-  pmtxGameStateLock->acquire();
-  cout << endl << "---Noise ON..." << endl;
-  pmtxGameStateLock->release();
-  for ( int i = 0; i < 100000; i++ )
-    pcndGameStateChange->broadcast();
-  cout << endl << "---Noise OFF" << endl;
-  // Set game over state
-  pmtxGameStateLock->acquire();
-  eGameState = GAME_OVER;
-  cout << endl << "---Stopping the game..." << endl;
-  // Let them know
-  pcndGameStateChange->broadcast();
-  // Wait for players to stop
-  do {
-    pcndGameStateChange->wait();
-  } while ( eGameState < BOTH_PLAYERS_GONE );
-  // Cleanup
-  cout << endl << "GAME OVER" << endl;
-  pmtxGameStateLock->release();
-  delete pcndGameStateChange;
-  delete pmtxGameStateLock;
-  return 0;
-}
-.
-.
-.
-David Schwartz <davids@webmaster.com> wrote:
->> > It's compliant
->>
->> That is really good.
->
->> Tomorrow (I have to go urgently now) I will try to
->> demonstrate the lost-signal "problem" of current
->> pthread-win32 and ACE-(variant w/o SingleObjectAndWait)
->> implementations: players start suddenly drop their balls :-)
->> (with no change in source code).
->
->Signals aren't lost, they're going to the main thread,
->which isn't coded correctly to handle them. Try this:
->
->  // Wait for players to stop
->  do {
->
->    pthread_cond_wait( &cndGameStateChange,&mtxGameStateLock );
->printf("Main thread stole a signal\n");
->
->  } while ( eGameState < BOTH_PLAYERS_GONE );
->
->I bet everytime you thing a signal is lost, you'll see that printf.
->The signal isn't lost, it was stolen by another thread.
-well, you can probably loose your bet.. it was indeed stolen
-by "another" thread but not the one you seem to think of.
-I think that what actually happens is the following:
-H:\SA\UXX\pt\PTHREADS\TESTS>tennis3.exe
-PLAYER-A
-PLAYER-B
-----PLAYER-B: SPURIOUS WAKEUP!!!
-PLAYER-A GONE
-PLAYER-B GONE
-GAME OVER
-H:\SA\UXX\pt\PTHREADS\TESTS>
-here you can see that PLAYER-B after playing his first
-ball (which came via signal from PLAYER-A) just dropped
-it down. What happened is that his signal to player A
-was consumed as spurious wakeup by himself (player B).
-The implementation has a problem:
-================
-waiting threads:
-================
-{ /** Critical Section
-  inc cond.waiters_count
-}
-  /*
-  /* Atomic only if using Win32 SignalObjectAndWait
-  /*
-  cond.mtx.release
-  /*** ^^-- A THREAD WHICH DID SIGNAL MAY ACQUIRE THE MUTEX,
-  /***      GO INTO WAIT ON THE SAME CONDITION AND OVERTAKE
-  /***      ORIGINAL WAITER(S) CONSUMING ITS OWN SIGNAL!
-  cond.sem.wait
-Player-A after playing game's initial ball went into
-wait (called _wait) but was pre-empted before reaching
-wait semaphore. He was counted as waiter but was not
-actually waiting/blocked yet.
-===============
-signal threads:
-===============
-{ /** Critical Section
-  waiters_count = cond.waiters_count
-}
-  if ( waiters_count != 0 )
-    sem.post 1
-  endif
-Player-B after he received signal/ball from Player A
-called _signal. The _signal did see that there was
-one waiter blocked on the condition (Player-A) and
-released the semaphore.. (but it did not unblock
-Player-A because he was not actually blocked).
-Player-B thread continued its execution, called _wait,
-was counted as second waiter BUT was allowed to slip
-through opened semaphore gate (which was opened for
-Player-B) and received his own signal. Player B remained
-blocked followed by Player A. Deadlock happened which
-lasted until main thread came in and said game over.
-It seems to me that the implementation fails to
-correctly implement the following statement
-from specification:
-http://www.opengroup.org/
-onlinepubs/007908799/xsh/pthread_cond_wait.html
-"These functions atomically release mutex and cause
-the calling thread to block on the condition variable
-cond; atomically here means "atomically with respect
-to access by another thread to the mutex and then the
-condition variable". That is, if another thread is
-able to acquire the mutex after the about-to-block
-thread has released it, then a subsequent call to
-pthread_cond_signal() or pthread_cond_broadcast()
-in that thread behaves as if it were issued after
-the about-to-block thread has blocked."
-Question: Am I right?
-(I produced the program output above by simply
-adding ?Sleep( 1 )?:
-================
-waiting threads:
-================
-{ /** Critical Section
-  inc cond.waiters_count
-}
-  /*
-  /* Atomic only if using Win32 SignalObjectAndWait
-  /*
-  cond.mtx.release
-Sleep( 1 ); // Win32
-  /*** ^^-- A THREAD WHICH DID SIGNAL MAY ACQUIRE THE MUTEX,
-  /***      GO INTO WAIT ON THE SAME CONDITION AND OVERTAKE
-  /***      ORIGINAL WAITER(S) CONSUMING ITS OWN SIGNAL!
-  cond.sem.wait
-to the source code of pthread-win32 implementation:
-http://sources.redhat.com/cgi-bin/cvsweb.cgi/pthreads/
-condvar.c?rev=1.36&content-type=text/
-x-cvsweb-markup&cvsroot=pthreads-win32
-  /*
-  * We keep the lock held just long enough to increment the count of
-  * waiters by one (above).
-  * Note that we can't keep it held across the
-  * call to sem_wait since that will deadlock other calls
-  * to pthread_cond_signal
-  */
-  cleanup_args.mutexPtr = mutex;
-  cleanup_args.cv = cv;
-  cleanup_args.resultPtr = &result;
-  pthread_cleanup_push (ptw32_cond_wait_cleanup, (void *)
-&cleanup_args);
-  if ((result = pthread_mutex_unlock (mutex)) == 0)
-    {((result
-Sleep( 1 ); // @AT
-      /*
-      * Wait to be awakened by
-      *              pthread_cond_signal, or
-      *              pthread_cond_broadcast, or
-      *              a timeout
-      *
-      * Note:
-      *      ptw32_sem_timedwait is a cancelation point,
-      *      hence providing the
-      *      mechanism for making pthread_cond_wait a cancelation
-      *      point. We use the cleanup mechanism to ensure we
-      *      re-lock the mutex and decrement the waiters count
-      *      if we are canceled.
-      */
-      if (ptw32_sem_timedwait (&(cv->sema), abstime) == -1)         {
-          result = errno;
-        }
-    }
-  pthread_cleanup_pop (1);  /* Always cleanup */
-BTW, on my system (2 CPUs) I can manage to get
-signals lost even without any source code modification
-if I run the tennis program many times in different
-shell sessions.
-.
-.
-.
-David Schwartz <davids@webmaster.com> wrote:
->terekhov@my-deja.com wrote:
->
->> well, it might be that the program is in fact buggy.
->> but you did not show me any bug.
->
->You're right. I was close but not dead on. I was correct, however,
->that the code is buggy because it uses 'pthread_cond_signal' even
->though not any thread waiting on the condition variable can do the
->job. I was wrong in which thread could be waiting on the cv but
->unable to do the job.
-Okay, lets change 'pthread_cond_signal' to 'pthread_cond_broadcast'
-but also add some noise from main() right before declaring the game
-to be over (I need it in order to demonstrate another problem of
-pthread-win32/ACE implementations - broadcast deadlock)...
-.
-.
-.
-It is my understanding of POSIX conditions,
-that on correct implementation added noise
-in form of unnecessary broadcasts from main,
-should not break the tennis program. The
-only 'side effect' of added noise on correct
-implementation would be 'spurious wakeups' of
-players (in fact they are not spurious,
-players just see them as spurious) unblocked,
-not by another player but by main before
-another player had a chance to acquire the
-mutex and change the game state variable:
-.
-.
-.
-PLAYER-B
-PLAYER-A
----Noise ON...
-PLAYER-B
-PLAYER-A
-.
-.
-.
-PLAYER-B
-PLAYER-A
-----PLAYER-A: SPURIOUS WAKEUP!!!
-PLAYER-B
-PLAYER-A
----Noise OFF
-PLAYER-B
----Stopping the game...
-PLAYER-A GONE
-PLAYER-B GONE
-GAME OVER
-H:\SA\UXX\pt\PTHREADS\TESTS>
-On pthread-win32/ACE implementations the
-program could stall:
-.
-.
-.
-PLAYER-A
-PLAYER-B
-PLAYER-A
-PLAYER-B
-PLAYER-A
-PLAYER-B
-PLAYER-A
-PLAYER-B
----Noise ON...
-PLAYER-A
----Noise OFF
-^C
-H:\SA\UXX\pt\PTHREADS\TESTS>
-The implementation has problems:
-================
-waiting threads:
-================
-{ /** Critical Section
-  inc cond.waiters_count
-}
-  /*
-  /* Atomic only if using Win32 SignalObjectAndWait
-  /*
-  cond.mtx.release
-  cond.sem.wait
-  /*** ^^-- WAITER CAN BE PREEMPTED AFTER BEING UNBLOCKED...
-{ /** Critical Section
-  dec cond.waiters_count
-  /*** ^^- ...AND BEFORE DECREMENTING THE COUNT (1)
-  last_waiter = ( cond.was_broadcast &&
-                    cond.waiters_count == 0 )
-  if ( last_waiter )
-    cond.was_broadcast = FALSE
-  endif
-}
-  if ( last_waiter )
-    /*
-    /* Atomic only if using Win32 SignalObjectAndWait
-    /*
-    cond.auto_reset_event_or_sem.post /* Event for Win32
-    cond.mtx.acquire
-  /*** ^^-- ...AND BEFORE CALL TO mtx.acquire (2)
-  /*** ^^-- NESTED BROADCASTS RESULT IN A DEADLOCK
-  else
-    cond.mtx.acquire
-  /*** ^^-- ...AND BEFORE CALL TO mtx.acquire (3)
-  endif
-==================
-broadcast threads:
-==================
-{ /** Critical Section
-  waiters_count = cond.waiters_count
-  if ( waiters_count != 0 )
-    cond.was_broadcast = TRUE
-  endif
-}
-if ( waiters_count != 0 )
-  cond.sem.post waiters_count
-  /*** ^^^^^--- SPURIOUS WAKEUPS DUE TO (1)
-  cond.auto_reset_event_or_sem.wait /* Event for Win32
-  /*** ^^^^^--- DEADLOCK FOR FURTHER BROADCASTS IF THEY
-                HAPPEN TO GO INTO WAIT WHILE PREVIOUS
-                BROADCAST IS STILL IN PROGRESS/WAITING
-endif
-a) cond.waiters_count does not accurately reflect
-number of waiters blocked on semaphore - that could
-result (in the time window when counter is not accurate)
-in spurios wakeups organised by subsequent _signals
-and _broadcasts. From standard compliance point of view
-that is OK but that could be a real problem from
-performance/efficiency point of view.
-b) If subsequent broadcast happen to go into wait on
-cond.auto_reset_event_or_sem before previous
-broadcast was unblocked from cond.auto_reset_event_or_sem
-by its last waiter, one of two blocked threads will
-remain blocked because last_waiter processing code
-fails to unblock both threads.
-In the situation with tennisb.c the Player-B was put
-in a deadlock by noise (broadcast) coming from main
-thread. And since Player-B holds the game state
-mutex when it calls broadcast, the whole program
-stalled: Player-A was deadlocked on mutex and
-main thread after finishing with producing the noise
-was deadlocked on mutex too (needed to declare the
-game over)
-(I produced the program output above by simply
-adding ?Sleep( 1 )?:
-==================
-broadcast threads:
-==================
-{ /** Critical Section
-  waiters_count = cond.waiters_count
-  if ( waiters_count != 0 )
-    cond.was_broadcast = TRUE
-  endif
-}
-if ( waiters_count != 0 )
-Sleep( 1 ); //Win32
-  cond.sem.post waiters_count
-  /*** ^^^^^--- SPURIOUS WAKEUPS DUE TO (1)
-  cond.auto_reset_event_or_sem.wait /* Event for Win32
-  /*** ^^^^^--- DEADLOCK FOR FURTHER BROADCASTS IF THEY
-                HAPPEN TO GO INTO WAIT WHILE PREVIOUS
-                BROADCAST IS STILL IN PROGRESS/WAITING
-endif
-to the source code of pthread-win32 implementation:
-http://sources.redhat.com/cgi-bin/cvsweb.cgi/pthreads/
-condvar.c?rev=1.36&content-type=text/
-x-cvsweb-markup&cvsroot=pthreads-win32
-  if (wereWaiters)
-    {(wereWaiters)sroot=pthreads-win32eb.cgi/pthreads/Yem...m
-      /*
-      * Wake up all waiters
-      */
-Sleep( 1 ); //@AT
-#ifdef NEED_SEM
-      result = (ptw32_increase_semaphore( &cv->sema, cv->waiters )
-                 ? 0
-                : EINVAL);
-#else /* NEED_SEM */
-      result = (ReleaseSemaphore( cv->sema, cv->waiters, NULL )
-                 ? 0
-                : EINVAL);
-#endif /* NEED_SEM */
-    }
-  (void) pthread_mutex_unlock(&(cv->waitersLock));
-  if (wereWaiters && result == 0)
-    {(wereWaiters
-      /*
-       * Wait for all the awakened threads to acquire their part of
-       * the counting semaphore
-       */
-      if (WaitForSingleObject (cv->waitersDone, INFINITE)
-          == WAIT_OBJECT_0)
-        {
-          result = 0;
-        }
-      else
-        {
-          result = EINVAL;
-        }
-    }
-  return (result);
-}
-BTW, on my system (2 CPUs) I can manage to get
-the program stalled even without any source code
-modification if I run the tennisb program many
-times in different shell sessions.
-===================
-pthread-win32 patch
-===================
-struct pthread_cond_t_ {
-  long            nWaitersBlocked;   /* Number of threads blocked
-*/
-  long            nWaitersUnblocked; /* Number of threads unblocked
-*/
-  long            nWaitersToUnblock; /* Number of threads to unblock
-*/
-  sem_t           semBlockQueue;     /* Queue up threads waiting for the
-*/
-                                     /*   condition to become signalled
-*/
-  sem_t           semBlockLock;      /* Semaphore that guards access to
-*/
-                                     /* | waiters blocked count/block queue
-*/
-                                     /* +-> Mandatory Sync.LEVEL-1
-*/
-  pthread_mutex_t mtxUnblockLock;    /* Mutex that guards access to
-*/
-                                     /* | waiters (to)unblock(ed) counts
-*/
-                                     /* +-> Optional* Sync.LEVEL-2
-*/
-};                                   /* Opt*) for _timedwait and
-cancellation*/
-int
-pthread_cond_init (pthread_cond_t * cond, const pthread_condattr_t * attr)
-  int result = EAGAIN;
-  pthread_cond_t cv = NULL;
-  if (cond == NULL)
-    {(cond
-      return EINVAL;
-    }
-  if ((attr != NULL && *attr != NULL) &&
-      ((*attr)->pshared == PTHREAD_PROCESS_SHARED))
-    {
-      /*
-       * Creating condition variable that can be shared between
-       * processes.
-       */
-      result = ENOSYS;
-      goto FAIL0;
-    }
-  cv = (pthread_cond_t) calloc (1, sizeof (*cv));
-  if (cv == NULL)
-    {(cv
-      result = ENOMEM;
-      goto FAIL0;
-    }
-  cv->nWaitersBlocked   = 0;
-  cv->nWaitersUnblocked = 0;
-  cv->nWaitersToUnblock = 0;
-  if (sem_init (&(cv->semBlockLock), 0, 1) != 0)
-    {(sem_init
-      goto FAIL0;
-    }
-  if (sem_init (&(cv->semBlockQueue), 0, 0) != 0)
-    {(sem_init
-      goto FAIL1;
-    }
-  if (pthread_mutex_init (&(cv->mtxUnblockLock), 0) != 0)
-    {(pthread_mutex_init
-      goto FAIL2;
-    }
-  result = 0;
-  goto DONE;
-  /*
-   * -------------
-   * Failed...
-   * -------------
-   */
-FAIL2:
-  (void) sem_destroy (&(cv->semBlockQueue));
-FAIL1:
-  (void) sem_destroy (&(cv->semBlockLock));
-FAIL0:
-DONE:
-  *cond = cv;
-  return (result);
-}                               /* pthread_cond_init */
-int
-pthread_cond_destroy (pthread_cond_t * cond)
-{
-  int result = 0;
-  pthread_cond_t cv;
-  /*
-   * Assuming any race condition here is harmless.
-   */
-  if (cond == NULL
-      || *cond == NULL)
-    {
-      return EINVAL;
-    }
-  if (*cond != (pthread_cond_t) PTW32_OBJECT_AUTO_INIT)
-    {(*cond
-      cv = *cond;
-      /*
-       * Synchronize access to waiters blocked count (LEVEL-1)
-       */
-      if (sem_wait(&(cv->semBlockLock)) != 0)
-        {(sem_wait(&(cv->semBlockLock))
-          return errno;
-        }
-      /*
-       * Synchronize access to waiters (to)unblock(ed) counts (LEVEL-2)
-       */
-      if ((result = pthread_mutex_lock(&(cv->mtxUnblockLock))) != 0)
-        {((result
-          (void) sem_post(&(cv->semBlockLock));
-          return result;
-        }
-      /*
-       * Check whether cv is still busy (still has waiters blocked)
-       */
-      if (cv->nWaitersBlocked - cv->nWaitersUnblocked > 0)
-        {(cv->nWaitersBlocked
-          (void) sem_post(&(cv->semBlockLock));
-          (void) pthread_mutex_unlock(&(cv->mtxUnblockLock));
-          return EBUSY;
-        }
-      /*
-       * Now it is safe to destroy
-       */
-      (void) sem_destroy (&(cv->semBlockLock));
-      (void) sem_destroy (&(cv->semBlockQueue));
-      (void) pthread_mutex_unlock (&(cv->mtxUnblockLock));
-      (void) pthread_mutex_destroy (&(cv->mtxUnblockLock));
-      free(cv);
-      *cond = NULL;
-    }
-  else
-    {
-      /*
-       * See notes in ptw32_cond_check_need_init() above also.
-       */
-      EnterCriticalSection(&ptw32_cond_test_init_lock);
-      /*
-       * Check again.
-       */
-      if (*cond == (pthread_cond_t) PTW32_OBJECT_AUTO_INIT)
-        {(*cond
-          /*
-           * This is all we need to do to destroy a statically
-           * initialised cond that has not yet been used (initialised).
-           * If we get to here, another thread
-           * waiting to initialise this cond will get an EINVAL.
-           */
-          *cond = NULL;
-        }
-      else
-        {
-          /*
-           * The cv has been initialised while we were waiting
-           * so assume it's in use.
-           */
-          result = EBUSY;
-        }
-      LeaveCriticalSection(&ptw32_cond_test_init_lock);
-    }
-  return (result);
-}
-/*
- * Arguments for cond_wait_cleanup, since we can only pass a
- * single void * to it.
- */
-typedef struct {
-  pthread_mutex_t * mutexPtr;
-  pthread_cond_t cv;
-  int * resultPtr;
-} ptw32_cond_wait_cleanup_args_t;
-static void
-ptw32_cond_wait_cleanup(void * args)
-{
-  ptw32_cond_wait_cleanup_args_t * cleanup_args =
-(ptw32_cond_wait_cleanup_args_t *) args;
-  pthread_cond_t cv = cleanup_args->cv;
-  int * resultPtr = cleanup_args->resultPtr;
-  int eLastSignal; /* enum: 1=yes 0=no -1=cancelled/timedout w/o signal(s)
-*/
-  int result;
-  /*
-   * Whether we got here as a result of signal/broadcast or because of
-   * timeout on wait or thread cancellation we indicate that we are no
-   * longer waiting. The waiter is responsible for adjusting waiters
-   * (to)unblock(ed) counts (protected by unblock lock).
-   * Unblock lock/Sync.LEVEL-2 supports _timedwait and cancellation.
-   */
-  if ((result = pthread_mutex_lock(&(cv->mtxUnblockLock))) != 0)
-    {((result
-      *resultPtr = result;
-      return;
-    }
-  cv->nWaitersUnblocked++;
-  eLastSignal = (cv->nWaitersToUnblock == 0) ?
-                   -1 : (--cv->nWaitersToUnblock == 0);
-  /*
-   * No more LEVEL-2 access to waiters (to)unblock(ed) counts needed
-   */
-  if ((result = pthread_mutex_unlock(&(cv->mtxUnblockLock))) != 0)
-    {((result
-      *resultPtr = result;
-      return;
-    }
-  /*
-   * If last signal...
-   */
-  if (eLastSignal == 1)
-    {(eLastSignal
-     /*
-      * ...it means that we have end of 'atomic' signal/broadcast
-      */
-      if (sem_post(&(cv->semBlockLock)) != 0)
-        {(sem_post(&(cv->semBlockLock))
-          *resultPtr = errno;
-          return;
-        }
-    }
-  /*
-   * If not last signal and not timed out/cancelled wait w/o signal...
-   */
-  else if (eLastSignal == 0)
-    {
-     /*
-      * ...it means that next waiter can go through semaphore
-      */
-      if (sem_post(&(cv->semBlockQueue)) != 0)
-        {(sem_post(&(cv->semBlockQueue))
-          *resultPtr = errno;
-          return;
-        }
-    }
-  /*
-   * XSH: Upon successful return, the mutex has been locked and is owned
-   * by the calling thread
-   */
-  if ((result = pthread_mutex_lock(cleanup_args->mutexPtr)) != 0)
-    {((result
-      *resultPtr = result;
-    }
-}                               /* ptw32_cond_wait_cleanup */
-static int
-ptw32_cond_timedwait (pthread_cond_t * cond,
-                      pthread_mutex_t * mutex,
-                      const struct timespec *abstime)
-{
-  int result = 0;
-  pthread_cond_t cv;
-  ptw32_cond_wait_cleanup_args_t cleanup_args;
-  if (cond == NULL || *cond == NULL)
-    {(cond
-      return EINVAL;
-    }
-  /*
-   * We do a quick check to see if we need to do more work
-   * to initialise a static condition variable. We check
-   * again inside the guarded section of ptw32_cond_check_need_init()
-   * to avoid race conditions.
-   */
-  if (*cond == (pthread_cond_t) PTW32_OBJECT_AUTO_INIT)
-    {(*cond
-      result = ptw32_cond_check_need_init(cond);
-    }
-  if (result != 0 && result != EBUSY)
-    {(result
-      return result;
-    }
-  cv = *cond;
-  /*
-   * Synchronize access to waiters blocked count (LEVEL-1)
-   */
-  if (sem_wait(&(cv->semBlockLock)) != 0)
-    {(sem_wait(&(cv->semBlockLock))
-      return errno;
-    }
-  cv->nWaitersBlocked++;
-  /*
-   * Thats it. Counted means waiting, no more access needed
-   */
-  if (sem_post(&(cv->semBlockLock)) != 0)
-    {(sem_post(&(cv->semBlockLock))
-      return errno;
-    }
-  /*
-   * Setup this waiter cleanup handler
-   */
-  cleanup_args.mutexPtr = mutex;
-  cleanup_args.cv = cv;
-  cleanup_args.resultPtr = &result;
-  pthread_cleanup_push (ptw32_cond_wait_cleanup, (void *) &cleanup_args);
-  /*
-   * Now we can release 'mutex' and...
-   */
-  if ((result = pthread_mutex_unlock (mutex)) == 0)
-    {((result
-      /*
-       * ...wait to be awakened by
-       *              pthread_cond_signal, or
-       *              pthread_cond_broadcast, or
-       *              timeout, or
-       *              thread cancellation
-       *
-       * Note:
-       *
-       *      ptw32_sem_timedwait is a cancellation point,
-       *      hence providing the mechanism for making
-       *      pthread_cond_wait a cancellation point.
-       *      We use the cleanup mechanism to ensure we
-       *      re-lock the mutex and adjust (to)unblock(ed) waiters
-       *      counts if we are cancelled, timed out or signalled.
-       */
-      if (ptw32_sem_timedwait (&(cv->semBlockQueue), abstime) != 0)
-        {(ptw32_sem_timedwait
-          result = errno;
-        }
-    }
-  /*
-   * Always cleanup
-   */
-  pthread_cleanup_pop (1);
-  /*
-   * "result" can be modified by the cleanup handler.
-   */
-  return (result);
-}                               /* ptw32_cond_timedwait */
-static int
-ptw32_cond_unblock (pthread_cond_t * cond,
-                    int unblockAll)
-{
-  int result;
-  pthread_cond_t cv;
-  if (cond == NULL || *cond == NULL)
-    {(cond
-      return EINVAL;
-    }
-  cv = *cond;
-  /*
-   * No-op if the CV is static and hasn't been initialised yet.
-   * Assuming that any race condition is harmless.
-   */
-  if (cv == (pthread_cond_t) PTW32_OBJECT_AUTO_INIT)
-    {(cv
-      return 0;
-    }
-  /*
-   * Synchronize access to waiters blocked count (LEVEL-1)
-   */
-  if (sem_wait(&(cv->semBlockLock)) != 0)
-    {(sem_wait(&(cv->semBlockLock))
-      return errno;
-    }
-  /*
-   * Synchronize access to waiters (to)unblock(ed) counts (LEVEL-2)
-   * This sync.level supports _timedwait and cancellation
-   */
-  if ((result = pthread_mutex_lock(&(cv->mtxUnblockLock))) != 0)
-    {((result
-      return result;
-    }
-  /*
-   * Adjust waiters blocked and unblocked counts (collect garbage)
-   */
-  if (cv->nWaitersUnblocked != 0)
-    {(cv->nWaitersUnblocked
-      cv->nWaitersBlocked  -= cv->nWaitersUnblocked;
-      cv->nWaitersUnblocked = 0;
-    }
-  /*
-   * If (after adjustment) there are still some waiters blocked counted...
-   */
-  if ( cv->nWaitersBlocked > 0)
-    {(
-      /*
-       * We will unblock first waiter and leave semBlockLock/LEVEL-1 locked
-       * LEVEL-1 access is left disabled until last signal/unblock
-completes
-       */
-      cv->nWaitersToUnblock = (unblockAll) ? cv->nWaitersBlocked : 1;
-      /*
-       * No more LEVEL-2 access to waiters (to)unblock(ed) counts needed
-       * This sync.level supports _timedwait and cancellation
-       */
-      if ((result = pthread_mutex_unlock(&(cv->mtxUnblockLock))) != 0)
-        {((result
-          return result;
-        }
-      /*
-       * Now, with LEVEL-2 lock released let first waiter go through
-semaphore
-       */
-      if (sem_post(&(cv->semBlockQueue)) != 0)
-        {(sem_post(&(cv->semBlockQueue))
-          return errno;
-        }
-    }
-  /*
-   * No waiter blocked - no more LEVEL-1 access to blocked count needed...
-   */
-  else if (sem_post(&(cv->semBlockLock)) != 0)
-    {
-      return errno;
-    }
-  /*
-   * ...and no more LEVEL-2 access to waiters (to)unblock(ed) counts needed
-too
-   * This sync.level supports _timedwait and cancellation
-   */
-  else
-    {
-      result = pthread_mutex_unlock(&(cv->mtxUnblockLock));
-    }
-  return(result);
-}                               /* ptw32_cond_unblock */
-int
-pthread_cond_wait (pthread_cond_t * cond,
-                   pthread_mutex_t * mutex)
-{
-  /* The NULL abstime arg means INFINITE waiting. */
-  return(ptw32_cond_timedwait(cond, mutex, NULL));
-}                               /* pthread_cond_wait */
-int
-pthread_cond_timedwait (pthread_cond_t * cond,
-                        pthread_mutex_t * mutex,
-                        const struct timespec *abstime)
-{
-  if (abstime == NULL)
-    {(abstime
-      return EINVAL;
-    }
-  return(ptw32_cond_timedwait(cond, mutex, abstime));
-}                               /* pthread_cond_timedwait */
-int
-pthread_cond_signal (pthread_cond_t * cond)
-{
-  /* The '0'(FALSE) unblockAll arg means unblock ONE waiter. */
-  return(ptw32_cond_unblock(cond, 0));
-}                               /* pthread_cond_signal */
-int
-pthread_cond_broadcast (pthread_cond_t * cond)
-{
-  /* The '1'(TRUE) unblockAll arg means unblock ALL waiters. */
-  return(ptw32_cond_unblock(cond, 1));
-}                               /* pthread_cond_broadcast */
-TEREKHOV@de.ibm.com on 17.01.2001 01:00:57
-Please respond to TEREKHOV@de.ibm.com
-To:   pthreads-win32@sourceware.cygnus.com
-cc:   schmidt@uci.edu
-Subject:  win32 conditions: sem+counter+event = broadcast_deadlock +
-      spur.wakeup/unfairness/incorrectness ??
-Hi,
-Problem 1: broadcast_deadlock
-It seems that current implementation does not provide "atomic"
-broadcasts. That may lead to "nested" broadcasts... and it seems
-that nested case is not handled correctly -> producing a broadcast
-DEADLOCK as a result.
-Scenario:
-N (>1) waiting threads W1..N are blocked (in _wait) on condition's
-semaphore.
-Thread B1 calls pthread_cond_broadcast, which results in "releasing" N
-W threads via incrementing semaphore counter by N (stored in
-cv->waiters) BUT cv->waiters counter does not change!! The caller
-thread B1 remains blocked on cv->waitersDone event (auto-reset!!) BUT
-condition is not protected from starting another broadcast (when called
-on another thread) while still waiting for the "old" broadcast to
-complete on thread B1.
-M (>=0, <N) W threads are fast enough to go thru their _wait call and
-decrement cv->waiters counter.
-L (N-M) "late" waiter W threads are a) still blocked/not returned from
-their semaphore wait call or b) were preempted after sem_wait but before
-lock( &cv->waitersLock ) or c) are blocked on cv->waitersLock.
-cv->waiters is still > 0 (= L).
-Another thread B2 (or some W thread from M group) calls
-pthread_cond_broadcast and gains access to counter... neither a) nor b)
-prevent thread B2 in pthread_cond_broadcast from gaining access to
-counter and starting another broadcast ( for c) - it depends on
-cv->waitersLock scheduling rules: FIFO=OK, PRTY=PROBLEM,... )
-That call to pthread_cond_broadcast (on thread B2) will result in
-incrementing semaphore by cv->waiters (=L) which is INCORRECT (all
-W1..N were in fact already released by thread B1) and waiting on
-_auto-reset_ event cv->waitersDone which is DEADLY WRONG (produces a
-deadlock)...
-All late W1..L threads now have a chance to complete their _wait call.
-Last W_L thread sets an auto-reselt event cv->waitersDone which will
-release either B1 or B2 leaving one of B threads in a deadlock.
-Problem 2: spur.wakeup/unfairness/incorrectness
-It seems that:
-a) because of the same problem with counter which does not reflect the
-actual number of NOT RELEASED waiters, the signal call may increment
-a semaphore counter w/o having a waiter blocked on it. That will result
-in (best case) spurious wake ups - performance degradation due to
-unnecessary context switches and predicate re-checks and (in worth case)
-unfairness/incorrectness problem - see b)
-b) neither signal nor broadcast prevent other threads - "new waiters"
-(and in the case of signal, the caller thread as well) from going into
-_wait and overtaking "old" waiters (already released but still not returned
-from sem_wait on condition's semaphore). Win semaphore just [API DOC]:
-"Maintains a count between zero and some maximum value, limiting the number
-of threads that are simultaneously accessing a shared resource." Calling
-ReleaseSemaphore does not imply (at least not documented) that on return
-from ReleaseSemaphore all waiters will in fact become released (returned
-from their Wait... call) and/or that new waiters calling Wait... afterwards
-will become less importance. It is NOT documented to be an atomic release
-of
-waiters... And even if it would be there is still a problem with a thread
-being preempted after Wait on semaphore and before Wait on cv->waitersLock
-and scheduling rules for cv->waitersLock itself
-(??WaitForMultipleObjects??)
-That may result in unfairness/incorrectness problem as described
-for SetEvent impl. in "Strategies for Implementing POSIX Condition
-Variables
-on Win32": http://www.cs.wustl.edu/~schmidt/win32-cv-1.html
-Unfairness -- The semantics of the POSIX pthread_cond_broadcast function is
-to wake up all threads currently blocked in wait calls on the condition
-variable. The awakened threads then compete for the external_mutex. To
-ensure
-fairness, all of these threads should be released from their
-pthread_cond_wait calls and allowed to recheck their condition expressions
-before other threads can successfully complete a wait on the condition
-variable.
-Unfortunately, the SetEvent implementation above does not guarantee that
-all
-threads sleeping on the condition variable when cond_broadcast is called
-will
-acquire the external_mutex and check their condition expressions. Although
-the Pthreads specification does not mandate this degree of fairness, the
-lack of fairness can cause starvation.
-To illustrate the unfairness problem, imagine there are 2 threads, C1 and
-C2,
-that are blocked in pthread_cond_wait on condition variable not_empty_ that
-is guarding a thread-safe message queue. Another thread, P1 then places two
-messages onto the queue and calls pthread_cond_broadcast. If C1 returns
-from
-pthread_cond_wait, dequeues and processes the message, and immediately
-waits
-again then it and only it may end up acquiring both messages. Thus, C2 will
-never get a chance to dequeue a message and run.
-The following illustrates the sequence of events:
-1.   Thread C1 attempts to dequeue and waits on CV non_empty_
-2.   Thread C2 attempts to dequeue and waits on CV non_empty_
-3.   Thread P1 enqueues 2 messages and broadcasts to CV not_empty_
-4.   Thread P1 exits
-5.   Thread C1 wakes up from CV not_empty_, dequeues a message and runs
-6.   Thread C1 waits again on CV not_empty_, immediately dequeues the 2nd
-        message and runs
-7.   Thread C1 exits
-8.   Thread C2 is the only thread left and blocks forever since
-        not_empty_ will never be signaled
-Depending on the algorithm being implemented, this lack of fairness may
-yield
-concurrent programs that have subtle bugs. Of course, application
-developers
-should not rely on the fairness semantics of pthread_cond_broadcast.
-However,
-there are many cases where fair implementations of condition variables can
-simplify application code.
-Incorrectness -- A variation on the unfairness problem described above
-occurs
-when a third consumer thread, C3, is allowed to slip through even though it
-was not waiting on condition variable not_empty_ when a broadcast occurred.
-To illustrate this, we will use the same scenario as above: 2 threads, C1
-and
-C2, are blocked dequeuing messages from the message queue. Another thread,
-P1
-then places two messages onto the queue and calls pthread_cond_broadcast.
-C1
-returns from pthread_cond_wait, dequeues and processes the message. At this
-time, C3 acquires the external_mutex, calls pthread_cond_wait and waits on
-the events in WaitForMultipleObjects. Since C2 has not had a chance to run
-yet, the BROADCAST event is still signaled. C3 then returns from
-WaitForMultipleObjects, and dequeues and processes the message in the
-queue.
-Thus, C2 will never get a chance to dequeue a message and run.
-The following illustrates the sequence of events:
-1.   Thread C1 attempts to dequeue and waits on CV non_empty_
-2.   Thread C2 attempts to dequeue and waits on CV non_empty_
-3.   Thread P1 enqueues 2 messages and broadcasts to CV not_empty_
-4.   Thread P1 exits
-5.   Thread C1 wakes up from CV not_empty_, dequeues a message and runs
-6.   Thread C1 exits
-7.   Thread C3 waits on CV not_empty_, immediately dequeues the 2nd
-        message and runs
-8.   Thread C3 exits
-9.   Thread C2 is the only thread left and blocks forever since
-        not_empty_ will never be signaled
-In the above case, a thread that was not waiting on the condition variable
-when a broadcast occurred was allowed to proceed. This leads to incorrect
-semantics for a condition variable.
-COMMENTS???
-regards,
-alexander.
------------------------------------------------------------------------------
-Subject: RE: FYI/comp.programming.threads/Re: pthread_cond_*
-     implementation questions
-Date: Wed, 21 Feb 2001 11:54:47 +0100
-From: TEREKHOV@de.ibm.com
-To: lthomas@arbitrade.com
-CC: rpj@ise.canberra.edu.au, Thomas Pfaff <tpfaff@gmx.net>,
-     Nanbor Wang <nanbor@cs.wustl.edu>
-Hi Louis,
-generation number 8..
-had some time to revisit timeouts/spurious wakeup problem..
-found some bugs (in 7.b/c/d) and something to improve
-(7a - using IPC semaphores but it should speedup Win32
-version as well).
-regards,
-alexander.
----------- Algorithm 8a / IMPL_SEM,UNBLOCK_STRATEGY == UNBLOCK_ALL ------
-given:
-semBlockLock - bin.semaphore
-semBlockQueue - semaphore
-mtxExternal - mutex or CS
-mtxUnblockLock - mutex or CS
-nWaitersGone - int
-nWaitersBlocked - int
-nWaitersToUnblock - int
-wait( timeout ) {
-  [auto: register int result          ]     // error checking omitted
-  [auto: register int nSignalsWasLeft ]
-  [auto: register int nWaitersWasGone ]
-  sem_wait( semBlockLock );
-  nWaitersBlocked++;
-  sem_post( semBlockLock );
-  unlock( mtxExternal );
-  bTimedOut = sem_wait( semBlockQueue,timeout );
-  lock( mtxUnblockLock );
-  if ( 0 != (nSignalsWasLeft = nWaitersToUnblock) ) {
-    if ( bTimeout ) {                       // timeout (or canceled)
-      if ( 0 != nWaitersBlocked ) {
-        nWaitersBlocked--;
-      }
-      else {
-        nWaitersGone++;                     // count spurious wakeups
-      }
-    }
-    if ( 0 == --nWaitersToUnblock ) {
-      if ( 0 != nWaitersBlocked ) {
-        sem_post( semBlockLock );           // open the gate
-        nSignalsWasLeft = 0;                // do not open the gate below
-again
-      }
-      else if ( 0 != (nWaitersWasGone = nWaitersGone) ) {
-        nWaitersGone = 0;
-      }
-    }
-  }
-  else if ( INT_MAX/2 == ++nWaitersGone ) { // timeout/canceled or spurious
-semaphore :-)
-    sem_wait( semBlockLock );
-    nWaitersBlocked -= nWaitersGone;        // something is going on here -
-test of timeouts? :-)
-    sem_post( semBlockLock );
-    nWaitersGone = 0;
-  }
-  unlock( mtxUnblockLock );
-  if ( 1 == nSignalsWasLeft ) {
-    if ( 0 != nWaitersWasGone ) {
-      // sem_adjust( -nWaitersWasGone );
-      while ( nWaitersWasGone-- ) {
-        sem_wait( semBlockLock );          // better now than spurious
-later
-      }
-    }
-    sem_post( semBlockLock );              // open the gate
-  }
-  lock( mtxExternal );
-  return ( bTimedOut ) ? ETIMEOUT : 0;
-}
-signal(bAll) {
-  [auto: register int result         ]
-  [auto: register int nSignalsToIssue]
-  lock( mtxUnblockLock );
-  if ( 0 != nWaitersToUnblock ) { // the gate is closed!!!
-    if ( 0 == nWaitersBlocked ) { // NO-OP
-      return unlock( mtxUnblockLock );
-    }
-    if (bAll) {
-      nWaitersToUnblock += nSignalsToIssue=nWaitersBlocked;
-      nWaitersBlocked = 0;
-    }
-    else {
-      nSignalsToIssue = 1;
-      nWaitersToUnblock++;
-      nWaitersBlocked--;
-    }
-  }
-  else if ( nWaitersBlocked > nWaitersGone ) { // HARMLESS RACE CONDITION!
-    sem_wait( semBlockLock ); // close the gate
-    if ( 0 != nWaitersGone ) {
-      nWaitersBlocked -= nWaitersGone;
-      nWaitersGone = 0;
-    }
-    if (bAll) {
-      nSignalsToIssue = nWaitersToUnblock = nWaitersBlocked;
-      nWaitersBlocked = 0;
-    }
-    else {
-      nSignalsToIssue = nWaitersToUnblock = 1;
-      nWaitersBlocked--;
-    }
-  }
-  else { // NO-OP
-    return unlock( mtxUnblockLock );
-  }
-  unlock( mtxUnblockLock );
-  sem_post( semBlockQueue,nSignalsToIssue );
-  return result;
-}
----------- Algorithm 8b / IMPL_SEM,UNBLOCK_STRATEGY == UNBLOCK_ONEBYONE
-------
-given:
-semBlockLock - bin.semaphore
-semBlockQueue - bin.semaphore
-mtxExternal - mutex or CS
-mtxUnblockLock - mutex or CS
-nWaitersGone - int
-nWaitersBlocked - int
-nWaitersToUnblock - int
-wait( timeout ) {
-  [auto: register int result          ]     // error checking omitted
-  [auto: register int nWaitersWasGone ]
-  [auto: register int nSignalsWasLeft ]
-  sem_wait( semBlockLock );
-  nWaitersBlocked++;
-  sem_post( semBlockLock );
-  unlock( mtxExternal );
-  bTimedOut = sem_wait( semBlockQueue,timeout );
-  lock( mtxUnblockLock );
-  if ( 0 != (nSignalsWasLeft = nWaitersToUnblock) ) {
-    if ( bTimeout ) {                       // timeout (or canceled)
-      if ( 0 != nWaitersBlocked ) {
-        nWaitersBlocked--;
-        nSignalsWasLeft = 0;                // do not unblock next waiter
-below (already unblocked)
-      }
-      else {
-        nWaitersGone = 1;                   // spurious wakeup pending!!
-      }
-    }
-    if ( 0 == --nWaitersToUnblock &&
-      if ( 0 != nWaitersBlocked ) {
-        sem_post( semBlockLock );           // open the gate
-        nSignalsWasLeft = 0;                // do not open the gate below
-again
-      }
-      else if ( 0 != (nWaitersWasGone = nWaitersGone) ) {
-        nWaitersGone = 0;
-      }
-    }
-  }
-  else if ( INT_MAX/2 == ++nWaitersGone ) { // timeout/canceled or spurious
-semaphore :-)
-    sem_wait( semBlockLock );
-    nWaitersBlocked -= nWaitersGone;        // something is going on here -
-test of timeouts? :-)
-    sem_post( semBlockLock );
-    nWaitersGone = 0;
-  }
-  unlock( mtxUnblockLock );
-  if ( 1 == nSignalsWasLeft ) {
-    if ( 0 != nWaitersWasGone ) {
-      // sem_adjust( -1 );
-      sem_wait( semBlockQueue );           // better now than spurious
-later
-    }
-    sem_post( semBlockLock );              // open the gate
-  }
-  else if ( 0 != nSignalsWasLeft ) {
-    sem_post( semBlockQueue );             // unblock next waiter
-  }
-  lock( mtxExternal );
-  return ( bTimedOut ) ? ETIMEOUT : 0;
-}
-signal(bAll) {
-  [auto: register int result ]
-  lock( mtxUnblockLock );
-  if ( 0 != nWaitersToUnblock ) { // the gate is closed!!!
-    if ( 0 == nWaitersBlocked ) { // NO-OP
-      return unlock( mtxUnblockLock );
-    }
-    if (bAll) {
-      nWaitersToUnblock += nWaitersBlocked;
-      nWaitersBlocked = 0;
-    }
-    else {
-      nWaitersToUnblock++;
-      nWaitersBlocked--;
-    }
-    unlock( mtxUnblockLock );
-  }
-  else if ( nWaitersBlocked > nWaitersGone ) { // HARMLESS RACE CONDITION!
-    sem_wait( semBlockLock ); // close the gate
-    if ( 0 != nWaitersGone ) {
-      nWaitersBlocked -= nWaitersGone;
-      nWaitersGone = 0;
-    }
-    if (bAll) {
-      nWaitersToUnblock = nWaitersBlocked;
-      nWaitersBlocked = 0;
-    }
-    else {
-      nWaitersToUnblock = 1;
-      nWaitersBlocked--;
-    }
-    unlock( mtxUnblockLock );
-    sem_post( semBlockQueue );
-  }
-  else { // NO-OP
-    unlock( mtxUnblockLock );
-  }
-  return result;
-}
----------- Algorithm 8c / IMPL_EVENT,UNBLOCK_STRATEGY == UNBLOCK_ONEBYONE
----------
-given:
-hevBlockLock - auto-reset event
-hevBlockQueue - auto-reset event
-mtxExternal - mutex or CS
-mtxUnblockLock - mutex or CS
-nWaitersGone - int
-nWaitersBlocked - int
-nWaitersToUnblock - int
-wait( timeout ) {
-  [auto: register int result          ]     // error checking omitted
-  [auto: register int nSignalsWasLeft ]
-  [auto: register int nWaitersWasGone ]
-  wait( hevBlockLock,INFINITE );
-  nWaitersBlocked++;
-  set_event( hevBlockLock );
-  unlock( mtxExternal );
-  bTimedOut = wait( hevBlockQueue,timeout );
-  lock( mtxUnblockLock );
-  if ( 0 != (SignalsWasLeft = nWaitersToUnblock) ) {
-    if ( bTimeout ) {                       // timeout (or canceled)
-      if ( 0 != nWaitersBlocked ) {
-        nWaitersBlocked--;
-        nSignalsWasLeft = 0;                // do not unblock next waiter
-below (already unblocked)
-      }
-      else {
-        nWaitersGone = 1;                   // spurious wakeup pending!!
-      }
-    }
-    if ( 0 == --nWaitersToUnblock )
-      if ( 0 != nWaitersBlocked ) {
-        set_event( hevBlockLock );          // open the gate
-        nSignalsWasLeft = 0;                // do not open the gate below
-again
-      }
-      else if ( 0 != (nWaitersWasGone = nWaitersGone) ) {
-        nWaitersGone = 0;
-      }
-    }
-  }
-  else if ( INT_MAX/2 == ++nWaitersGone ) { // timeout/canceled or spurious
-event :-)
-    wait( hevBlockLock,INFINITE );
-    nWaitersBlocked -= nWaitersGone;        // something is going on here -
-test of timeouts? :-)
-    set_event( hevBlockLock );
-    nWaitersGone = 0;
-  }
-  unlock( mtxUnblockLock );
-  if ( 1 == nSignalsWasLeft ) {
-    if ( 0 != nWaitersWasGone ) {
-      reset_event( hevBlockQueue );         // better now than spurious
-later
-    }
-    set_event( hevBlockLock );              // open the gate
-  }
-  else if ( 0 != nSignalsWasLeft ) {
-    set_event( hevBlockQueue );             // unblock next waiter
-  }
-  lock( mtxExternal );
-  return ( bTimedOut ) ? ETIMEOUT : 0;
-}
-signal(bAll) {
-  [auto: register int result ]
-  lock( mtxUnblockLock );
-  if ( 0 != nWaitersToUnblock ) { // the gate is closed!!!
-    if ( 0 == nWaitersBlocked ) { // NO-OP
-      return unlock( mtxUnblockLock );
-    }
-    if (bAll) {
-      nWaitersToUnblock += nWaitersBlocked;
-      nWaitersBlocked = 0;
-    }
-    else {
-      nWaitersToUnblock++;
-      nWaitersBlocked--;
-    }
-    unlock( mtxUnblockLock );
-  }
-  else if ( nWaitersBlocked > nWaitersGone ) { // HARMLESS RACE CONDITION!
-    wait( hevBlockLock,INFINITE ); // close the gate
-    if ( 0 != nWaitersGone ) {
-      nWaitersBlocked -= nWaitersGone;
-      nWaitersGone = 0;
-    }
-    if (bAll) {
-      nWaitersToUnblock = nWaitersBlocked;
-      nWaitersBlocked = 0;
-    }
-    else {
-      nWaitersToUnblock = 1;
-      nWaitersBlocked--;
-    }
-    unlock( mtxUnblockLock );
-    set_event( hevBlockQueue );
-  }
-  else { // NO-OP
-    unlock( mtxUnblockLock );
-  }
-  return result;
-}
----------- Algorithm 8d / IMPL_EVENT,UNBLOCK_STRATEGY == UNBLOCK_ALL ------
-given:
-hevBlockLock - auto-reset event
-hevBlockQueueS - auto-reset event  // for signals
-hevBlockQueueB - manual-reset even // for broadcasts
-mtxExternal - mutex or CS
-mtxUnblockLock - mutex or CS
-eBroadcast - int                   // 0: no broadcast, 1: broadcast, 2:
-broadcast after signal(s)
-nWaitersGone - int
-nWaitersBlocked - int
-nWaitersToUnblock - int
-wait( timeout ) {
-  [auto: register int result          ]     // error checking omitted
-  [auto: register int eWasBroadcast   ]
-  [auto: register int nSignalsWasLeft ]
-  [auto: register int nWaitersWasGone ]
-  wait( hevBlockLock,INFINITE );
-  nWaitersBlocked++;
-  set_event( hevBlockLock );
-  unlock( mtxExternal );
-  bTimedOut = waitformultiple( hevBlockQueueS,hevBlockQueueB,timeout,ONE );
-  lock( mtxUnblockLock );
-  if ( 0 != (SignalsWasLeft = nWaitersToUnblock) ) {
-    if ( bTimeout ) {                       // timeout (or canceled)
-      if ( 0 != nWaitersBlocked ) {
-        nWaitersBlocked--;
-        nSignalsWasLeft = 0;                // do not unblock next waiter
-below (already unblocked)
-      }
-      else if ( 1 != eBroadcast ) {
-        nWaitersGone = 1;
-      }
-    }
-    if ( 0 == --nWaitersToUnblock ) {
-      if ( 0 != nWaitersBlocked ) {
-        set_event( hevBlockLock );           // open the gate
-        nSignalsWasLeft = 0;                 // do not open the gate below
-again
-      }
-      else {
-        if ( 0 != (eWasBroadcast = eBroadcast) ) {
-          eBroadcast = 0;
-        }
-        if ( 0 != (nWaitersWasGone = nWaitersGone ) {
-          nWaitersGone = 0;
-        }
-      }
-    }
-    else if ( 0 != eBroadcast ) {
-      nSignalsWasLeft = 0;                  // do not unblock next waiter
-below (already unblocked)
-    }
-  }
-  else if ( INT_MAX/2 == ++nWaitersGone ) { // timeout/canceled or spurious
-event :-)
-    wait( hevBlockLock,INFINITE );
-    nWaitersBlocked -= nWaitersGone;        // something is going on here -
-test of timeouts? :-)
-    set_event( hevBlockLock );
-    nWaitersGone = 0;
-  }
-  unlock( mtxUnblockLock );
-  if ( 1 == nSignalsWasLeft ) {
-    if ( 0 != eWasBroadcast ) {
-      reset_event( hevBlockQueueB );
-    }
-    if ( 0 != nWaitersWasGone ) {
-      reset_event( hevBlockQueueS );        // better now than spurious
-later
-    }
-    set_event( hevBlockLock );              // open the gate
-  }
-  else if ( 0 != nSignalsWasLeft ) {
-    set_event( hevBlockQueueS );            // unblock next waiter
-  }
-  lock( mtxExternal );
-  return ( bTimedOut ) ? ETIMEOUT : 0;
-}
-signal(bAll) {
-  [auto: register int    result        ]
-  [auto: register HANDLE hevBlockQueue ]
-  lock( mtxUnblockLock );
-  if ( 0 != nWaitersToUnblock ) { // the gate is closed!!!
-    if ( 0 == nWaitersBlocked ) { // NO-OP
-      return unlock( mtxUnblockLock );
-    }
-    if (bAll) {
-      nWaitersToUnblock += nWaitersBlocked;
-      nWaitersBlocked = 0;
-      eBroadcast = 2;
-      hevBlockQueue = hevBlockQueueB;
-    }
-    else {
-      nWaitersToUnblock++;
-      nWaitersBlocked--;
-      return unlock( mtxUnblockLock );
-    }
-  }
-  else if ( nWaitersBlocked > nWaitersGone ) { // HARMLESS RACE CONDITION!
-    wait( hevBlockLock,INFINITE ); // close the gate
-    if ( 0 != nWaitersGone ) {
-      nWaitersBlocked -= nWaitersGone;
-      nWaitersGone = 0;
-    }
-    if (bAll) {
-      nWaitersToUnblock = nWaitersBlocked;
-      nWaitersBlocked = 0;
-      eBroadcast = 1;
-      hevBlockQueue = hevBlockQueueB;
-    }
-    else {
-      nWaitersToUnblock = 1;
-      nWaitersBlocked--;
-      hevBlockQueue = hevBlockQueueS;
-    }
-  }
-  else { // NO-OP
-    return unlock( mtxUnblockLock );
-  }
-  unlock( mtxUnblockLock );
-  set_event( hevBlockQueue );
-  return result;
-}
----------------------- Forwarded by Alexander Terekhov/Germany/IBM on
-02/21/2001 09:13 AM ---------------------------
-Alexander Terekhov
-02/20/2001 04:33 PM
-To:   Louis Thomas <lthomas@arbitrade.com>
-cc:
-From: Alexander Terekhov/Germany/IBM@IBMDE
-Subject:  RE: FYI/comp.programming.threads/Re: pthread_cond_* implementatio
-      n questions
-Importance:    Normal
->Sorry, gotta take a break and work on something else for a while.
->Real work
->calls, unfortunately. I'll get back to you in two or three days.
-ok. no problem. here is some more stuff for pauses you might have
-in between :)
----------- Algorithm 7d / IMPL_EVENT,UNBLOCK_STRATEGY == UNBLOCK_ALL ------
-given:
-hevBlockLock - auto-reset event
-hevBlockQueueS - auto-reset event  // for signals
-hevBlockQueueB - manual-reset even // for broadcasts
-mtxExternal - mutex or CS
-mtxUnblockLock - mutex or CS
-bBroadcast - int
-nWaitersGone - int
-nWaitersBlocked - int
-nWaitersToUnblock - int
-wait( timeout ) {
-  [auto: register int result          ]     // error checking omitted
-  [auto: register int bWasBroadcast   ]
-  [auto: register int nSignalsWasLeft ]
-  wait( hevBlockLock,INFINITE );
-  nWaitersBlocked++;
-  set_event( hevBlockLock );
-  unlock( mtxExternal );
-  bTimedOut = waitformultiple( hevBlockQueueS,hevBlockQueueB,timeout,ONE );
-  lock( mtxUnblockLock );
-  if ( 0 != (SignalsWasLeft = nWaitersToUnblock) ) {
-    if ( bTimeout ) {                       // timeout (or canceled)
-      if ( 0 != nWaitersBlocked ) {
-        nWaitersBlocked--;
-        nSignalsWasLeft = 0;                // do not unblock next waiter
-below (already unblocked)
-      }
-      else if ( !bBroadcast ) {
-        wait( hevBlockQueueS,INFINITE );    // better now than spurious
-later
-      }
-    }
-    if ( 0 == --nWaitersToUnblock ) {
-      if ( 0 != nWaitersBlocked ) {
-        if ( bBroadcast ) {
-          reset_event( hevBlockQueueB );
-          bBroadcast = false;
-        }
-        set_event( hevBlockLock );           // open the gate
-        nSignalsWasLeft = 0;                 // do not open the gate below
-again
-      }
-      else if ( false != (bWasBroadcast = bBroadcast) ) {
-        bBroadcast = false;
-      }
-    }
-    else {
-      bWasBroadcast = bBroadcast;
-    }
-  }
-  else if ( INT_MAX/2 == ++nWaitersGone ) { // timeout/canceled or spurious
-event :-)
-    wait( hevBlockLock,INFINITE );
-    nWaitersBlocked -= nWaitersGone;        // something is going on here -
-test of timeouts? :-)
-    set_event( hevBlockLock );
-    nWaitersGone = 0;
-  }
-  unlock( mtxUnblockLock );
-  if ( 1 == nSignalsWasLeft ) {
-    if ( bWasBroadcast ) {
-      reset_event( hevBlockQueueB );
-    }
-    set_event( hevBlockLock );              // open the gate
-  }
-  else if ( 0 != nSignalsWasLeft && !bWasBroadcast ) {
-    set_event( hevBlockQueueS );            // unblock next waiter
-  }
-  lock( mtxExternal );
-  return ( bTimedOut ) ? ETIMEOUT : 0;
-}
-signal(bAll) {
-  [auto: register int    result        ]
-  [auto: register HANDLE hevBlockQueue ]
-  lock( mtxUnblockLock );
-  if ( 0 != nWaitersToUnblock ) { // the gate is closed!!!
-    if ( 0 == nWaitersBlocked ) { // NO-OP
-      return unlock( mtxUnblockLock );
-    }
-    if (bAll) {
-      nWaitersToUnblock += nWaitersBlocked;
-      nWaitersBlocked = 0;
-      bBroadcast = true;
-      hevBlockQueue = hevBlockQueueB;
-    }
-    else {
-      nWaitersToUnblock++;
-      nWaitersBlocked--;
-      return unlock( mtxUnblockLock );
-    }
-  }
-  else if ( nWaitersBlocked > nWaitersGone ) { // HARMLESS RACE CONDITION!
-    wait( hevBlockLock,INFINITE ); // close the gate
-    if ( 0 != nWaitersGone ) {
-      nWaitersBlocked -= nWaitersGone;
-      nWaitersGone = 0;
-    }
-    if (bAll) {
-      nWaitersToUnblock = nWaitersBlocked;
-      nWaitersBlocked = 0;
-      bBroadcast = true;
-      hevBlockQueue = hevBlockQueueB;
-    }
-    else {
-      nWaitersToUnblock = 1;
-      nWaitersBlocked--;
-      hevBlockQueue = hevBlockQueueS;
-    }
-  }
-  else { // NO-OP
-    return unlock( mtxUnblockLock );
-  }
-  unlock( mtxUnblockLock );
-  set_event( hevBlockQueue );
-  return result;
-}
-----------------------------------------------------------------------------
-Subject: RE: FYI/comp.programming.threads/Re: pthread_cond_* implementatio
-     n questions
-Date: Mon, 26 Feb 2001 22:20:12 -0600
-From: Louis Thomas <lthomas@arbitrade.com>
-To: "'TEREKHOV@de.ibm.com'" <TEREKHOV@de.ibm.com>
-CC: rpj@ise.canberra.edu.au, Thomas Pfaff <tpfaff@gmx.net>,
-     Nanbor Wang
-     <nanbor@cs.wustl.edu>
-Sorry all. Busy week.
-> this insures the fairness
-> which POSIX does not (e.g. two subsequent broadcasts - the gate does
-insure
-> that first wave waiters will start the race for the mutex before waiters
-> from the second wave - Linux pthreads process/unblock both waves
-> concurrently...)
-I'm not sure how we are any more fair about this than Linux. We certainly
-don't guarantee that the threads released by the first broadcast will get
-the external mutex before the threads of the second wave. In fact, it is
-possible that those threads will never get the external mutex if there is
-enough contention for it.
-> e.g. i was thinking about implementation with a pool of
-> N semaphores/counters [...]
-I considered that too. The problem is as you mentioned in a). You really
-need to assign threads to semaphores once you know how you want to wake them
-up, not when they first begin waiting which is the only time you can assign
-them.
-> well, i am not quite sure that i've fully understood your scenario,
-Hmm. Well, it think it's an important example, so I'll try again. First, we
-have thread A which we KNOW is waiting on a condition. As soon as it becomes
-unblocked for any reason, we will know because it will set a flag. Since the
-flag is not set, we are 100% confident that thread A is waiting on the
-condition. We have another thread, thread B, which has acquired the mutex
-and is about to wait on the condition. Thus it is pretty clear that at any
-point, either just A is waiting, or A and B are waiting. Now thread C comes
-along. C is about to do a broadcast on the condition. A broadcast is
-guaranteed to unblock all threads currently waiting on a condition, right?
-Again, we said that either just A is waiting, or A and B are both waiting.
-So, when C does its broadcast, depending upon whether B has started waiting
-or not, thread C will unblock A or unblock A and B. Either way, C must
-unblock A, right?
-Now, you said anything that happens is correct so long as a) "a signal is
-not lost between unlocking the mutex and waiting on the condition" and b) "a
-thread must not steal a signal it sent", correct? Requirement b) is easy to
-satisfy: in this scenario, thread C will never wait on the condition, so it
-won't steal any signals.  Requirement a) is not hard either. The only way we
-could fail to meet requirement a) in this scenario is if thread B was
-started waiting but didn't wake up because a signal was lost. This will not
-happen.
-Now, here is what happens. Assume thread C beats thread B. Thread C looks to
-see how many threads are waiting on the condition. Thread C sees just one
-thread, thread A, waiting. It does a broadcast waking up just one thread
-because just one thread is waiting. Next, before A can become unblocked,
-thread B begins waiting. Now there are two threads waiting, but only one
-will be unblocked. Suppose B wins. B will become unblocked. A will not
-become unblocked, because C only unblocked one thread (sema_post cond, 1).
-So at the end, B finishes and A remains blocked.
-We have met both of your requirements, so by your rules, this is an
-acceptable outcome. However, I think that the spec says this is an
-unacceptable outcome! We know for certain that A was waiting and that C did
-a broadcast, but A did not become unblocked! Yet, the spec says that a
-broadcast wakes up all waiting threads. This did not happen. Do you agree
-that this shows your rules are not strict enough?
-> and what about N2? :) this one does allow almost everything.
-Don't get me started about rule #2. I'll NEVER advocate an algorithm that
-uses rule 2 as an excuse to suck!
-> but it is done (decrement)under mutex protection - this is not a subject
-> of a race condition.
-You are correct. My mistake.
-> i would remove "_bTimedOut=false".. after all, it was a real timeout..
-I disagree. A thread that can't successfully retract its waiter status can't
-really have timed out. If a thread can't return without executing extra code
-to deal with the fact that someone tried to unblock it, I think it is a poor
-idea to pretend we
-didn't realize someone was trying to signal us. After all, a signal is more
-important than a time out.
-> when nSignaled != 0, it is possible to update nWaiters (--) and do not
-> touch nGone
-I realize this, but I was thinking that writing it the other ways saves
-another if statement.
-> adjust only if nGone != 0 and save one cache memory write - probably much
-slower than 'if'
-Hmm. You are probably right.
-> well, in a strange (e.g. timeout test) program you may (theoretically)
-> have an overflow of nWaiters/nGone counters (with waiters repeatedly
-timing
-> out and no signals at all).
-Also true. Not only that, but you also have the possibility that one could
-overflow the number of waiters as well! However, considering the limit you
-have chosen for nWaitersGone, I suppose it is unlikely that anyone would be
-able to get INT_MAX/2 threads waiting on a single condition. :)
-Analysis of 8a:
-It looks correct to me.
-What are IPC semaphores?
-In the line where you state, "else if ( nWaitersBlocked > nWaitersGone ) {
-// HARMLESS RACE CONDITION!" there is no race condition for nWaitersGone
-because nWaitersGone is never modified without holding mtxUnblockLock. You
-are correct that there is a harmless race on nWaitersBlocked, which can
-increase and make the condition become true just after we check it. If this
-happens, we interpret it as the wait starting after the signal.
-I like your optimization of this. You could improve Alg. 6 as follows:
----------- Algorithm 6b ----------
-signal(bAll) {
-  _nSig=0
-  lock counters
-  // this is safe because nWaiting can only be decremented by a thread that
-  // owns counters and nGone can only be changed by a thread that owns
-counters.
-  if (nWaiting>nGone) {
-    if (0==nSignaled) {
-      sema_wait gate // close gate if not already closed
-    }
-    if (nGone>0) {
-      nWaiting-=nGone
-      nGone=0
-    }
-    _nSig=bAll?nWaiting:1
-    nSignaled+=_nSig
-    nWaiting-=_nSig
-  }
-  unlock counters
-  if (0!=_nSig) {
-    sema_post queue, _nSig
-  }
-}
----------- ---------- ----------
-I guess this wouldn't apply to Alg 8a because nWaitersGone changes meanings
-depending upon whether the gate is open or closed.
-In the loop "while ( nWaitersWasGone-- ) {" you do a sema_wait on
-semBlockLock. Perhaps waiting on semBlockQueue would be a better idea.
-What have you gained by making the last thread to be signaled do the waits
-for all the timed out threads, besides added complexity? It took me a long
-time to figure out what your objective was with this, to realize you were
-using nWaitersGone to mean two different things, and to verify that you
-hadn't introduced any bug by doing this. Even now I'm not 100% sure.
-What has all this playing about with nWaitersGone really gained us besides a
-lot of complexity (it is much harder to verify that this solution is
-correct), execution overhead (we now have a lot more if statements to
-evaluate), and space overhead (more space for the extra code, and another
-integer in our data)? We did manage to save a lock/unlock pair in an
-uncommon case (when a time out occurs) at the above mentioned expenses in
-the common cases.
-As for 8b, c, and d, they look ok though I haven't studied them thoroughly.
-What would you use them for?
-    Later,
-        -Louis! :)
------------------------------------------------------------------------------
-Subject: RE: FYI/comp.programming.threads/Re: pthread_cond_* implementatio
-     n questions
-Date: Tue, 27 Feb 2001 15:51:28 +0100
-From: TEREKHOV@de.ibm.com
-To: Louis Thomas <lthomas@arbitrade.com>
-CC: rpj@ise.canberra.edu.au, Thomas Pfaff <tpfaff@gmx.net>,
-     Nanbor Wang <nanbor@cs.wustl.edu>
-Hi Louis,
->> that first wave waiters will start the race for the mutex before waiters
->> from the second wave - Linux pthreads process/unblock both waves
->> concurrently...)
->
->I'm not sure how we are any more fair about this than Linux. We certainly
->don't guarantee that the threads released by the first broadcast will get
->the external mutex before the threads of the second wave. In fact, it is
->possible that those threads will never get the external mutex if there is
->enough contention for it.
-correct. but gate is nevertheless more fair than Linux because of the
-barrier it establishes between two races (1st and 2nd wave waiters) for
-the mutex which under 'normal' circumstances (e.g. all threads of equal
-priorities,..) will 'probably' result in fair behaviour with respect to
-mutex ownership.
->> well, i am not quite sure that i've fully understood your scenario,
->
->Hmm. Well, it think it's an important example, so I'll try again. ...
-ok. now i seem to understand this example. well, now it seems to me
-that the only meaningful rule is just:
-a) "a signal is not lost between unlocking the mutex and waiting on the
-condition"
-and that the rule
-b) "a thread must not steal a signal it sent"
-is not needed at all because a thread which violates b) also violates a).
-i'll try to explain..
-i think that the most important thing is how POSIX defines waiter's
-visibility:
-"if another thread is able to acquire the mutex after the about-to-block
-thread
-has released it, then a subsequent call to pthread_cond_signal() or
-pthread_cond_broadcast() in that thread behaves as if it were issued after
-the about-to-block thread has blocked. "
-my understanding is the following:
-1) there is no guarantees whatsoever with respect to whether
-signal/broadcast
-will actually unblock any 'waiter' if it is done w/o acquiring the mutex
-first
-(note that a thread may release it before signal/broadcast - it does not
-matter).
-2) it is guaranteed that waiters become 'visible' - eligible for unblock as
-soon
-as signalling thread acquires the mutex (but not before!!)
-so..
->So, when C does its broadcast, depending upon whether B has started
-waiting
->or not, thread C will unblock A or unblock A and B. Either way, C must
->unblock A, right?
-right. but only if C did acquire the mutex prior to broadcast (it may
-release it before broadcast as well).
-implementation will violate waiters visibility rule (signal will become
-lost)
-if C will not unblock A.
->Now, here is what happens. Assume thread C beats thread B. Thread C looks
-to
->see how many threads are waiting on the condition. Thread C sees just one
->thread, thread A, waiting. It does a broadcast waking up just one thread
->because just one thread is waiting. Next, before A can become unblocked,
->thread B begins waiting. Now there are two threads waiting, but only one
->will be unblocked. Suppose B wins. B will become unblocked. A will not
->become unblocked, because C only unblocked one thread (sema_post cond, 1).
->So at the end, B finishes and A remains blocked.
-thread C did acquire the mutex ("Thread C sees just one thread, thread A,
-waiting"). beginning from that moment it is guaranteed that subsequent
-broadcast will unblock A. Otherwise we will have a lost signal with respect
-to A. I do think that it does not matter whether the signal was physically
-(completely) lost or was just stolen by another thread (B) - in both cases
-it was simply lost with respect to A.
->..Do you agree that this shows your rules are not strict enough?
-probably the opposite.. :-) i think that it shows that the only meaningful
-rule is
-a) "a signal is not lost between unlocking the mutex and waiting on the
-condition"
-with clarification of waiters visibility as defined by POSIX above.
->> i would remove "_bTimedOut=false".. after all, it was a real timeout..
->
->I disagree. A thread that can't successfully retract its waiter status
-can't
->really have timed out. If a thread can't return without executing extra
-code
->to deal with the fact that someone tried to unblock it, I think it is a
-poor
->idea to pretend we
->didn't realize someone was trying to signal us. After all, a signal is
-more
->important than a time out.
-a) POSIX does allow timed out thread to consume a signal (cancelled is
-not).
-b) ETIMEDOUT status just says that: "The time specified by abstime to
-pthread_cond_timedwait() has passed."
-c) it seem to me that hiding timeouts would violate "The
-pthread_cond_timedwait()
-function is the same as pthread_cond_wait() except that an error is
-returned if
-the absolute time specified by abstime passes (that is, system time equals
-or
-exceeds abstime) before the condition cond is signaled or broadcasted"
-because
-the abs. time did really pass before cond was signaled (waiter was
-released via semaphore). however, if it really matters, i could imaging
-that we
-can save an abs. time of signal/broadcast and compare it with timeout after
-unblock to find out whether it was a 'real' timeout or not. absent this
-check
-i do think that hiding timeouts would result in technical violation of
-specification.. but i think that this check is not important and we can
-simply
-trust timeout error code provided by wait since we are not trying to make
-'hard' realtime implementation.
->What are IPC semaphores?
-<sys/sem.h>
-int   semctl(int, int, int, ...);
-int   semget(key_t, int, int);
-int   semop(int, struct sembuf *, size_t);
-they support adjustment of semaphore counter (semvalue)
-in one single call - imaging Win32 ReleaseSemaphore( hsem,-N )
->In the line where you state, "else if ( nWaitersBlocked > nWaitersGone ) {
->// HARMLESS RACE CONDITION!" there is no race condition for nWaitersGone
->because nWaitersGone is never modified without holding mtxUnblockLock. You
->are correct that there is a harmless race on nWaitersBlocked, which can
->increase and make the condition become true just after we check it. If
-this
->happens, we interpret it as the wait starting after the signal.
-well, the reason why i've asked on comp.programming.threads whether this
-race
-condition is harmless or not is that in order to be harmless it should not
-violate the waiters visibility rule (see above). Fortunately, we increment
-the counter under protection of external mutex.. so that any (signalling)
-thread which will acquire the mutex next, should see the updated counter
-(in signal) according to POSIX memory visibility rules and mutexes
-(memory barriers). But i am not so sure how it actually works on
-Win32/INTEL
-which does not explicitly define any memory visibility rules :(
->I like your optimization of this. You could improve Alg. 6 as follows:
->---------- Algorithm 6b ----------
->signal(bAll) {
->  _nSig=0
->  lock counters
->  // this is safe because nWaiting can only be decremented by a thread
-that
->  // owns counters and nGone can only be changed by a thread that owns
->counters.
->  if (nWaiting>nGone) {
->    if (0==nSignaled) {
->      sema_wait gate // close gate if not already closed
->    }
->    if (nGone>0) {
->      nWaiting-=nGone
->      nGone=0
->    }
->    _nSig=bAll?nWaiting:1
->    nSignaled+=_nSig
->    nWaiting-=_nSig
->  }
->  unlock counters
->  if (0!=_nSig) {
->    sema_post queue, _nSig
->  }
->}
->---------- ---------- ----------
->I guess this wouldn't apply to Alg 8a because nWaitersGone changes
-meanings
->depending upon whether the gate is open or closed.
-agree.
->In the loop "while ( nWaitersWasGone-- ) {" you do a sema_wait on
->semBlockLock. Perhaps waiting on semBlockQueue would be a better idea.
-you are correct. my mistake.
->What have you gained by making the last thread to be signaled do the waits
->for all the timed out threads, besides added complexity? It took me a long
->time to figure out what your objective was with this, to realize you were
->using nWaitersGone to mean two different things, and to verify that you
->hadn't introduced any bug by doing this. Even now I'm not 100% sure.
->
->What has all this playing about with nWaitersGone really gained us besides
-a
->lot of complexity (it is much harder to verify that this solution is
->correct), execution overhead (we now have a lot more if statements to
->evaluate), and space overhead (more space for the extra code, and another
->integer in our data)? We did manage to save a lock/unlock pair in an
->uncommon case (when a time out occurs) at the above mentioned expenses in
->the common cases.
-well, please consider the following:
-1) with multiple waiters unblocked (but some timed out) the trick with
-counter
-seem to ensure potentially higher level of concurrency by not delaying
-most of unblocked waiters for semaphore cleanup - only the last one
-will be delayed but all others would already contend/acquire/release
-the external mutex - the critical section protected by mtxUnblockLock is
-made smaller (increment + couple of IFs is faster than system/kernel call)
-which i think is good in general. however, you are right, this is done
-at expense of 'normal' waiters..
-2) some semaphore APIs (e.g. POSIX IPC sems) do allow to adjust the
-semaphore counter in one call => less system/kernel calls.. imagine:
-if ( 1 == nSignalsWasLeft ) {
-    if ( 0 != nWaitersWasGone ) {
-      ReleaseSemaphore( semBlockQueue,-nWaitersWasGone );  // better now
-than spurious later
-    }
-    sem_post( semBlockLock );              // open the gate
-  }
-3) even on win32 a single thread doing multiple cleanup calls (to wait)
-will probably result in faster execution (because of processor caching)
-than multiple threads each doing a single call to wait.
->As for 8b, c, and d, they look ok though I haven't studied them
-thoroughly.
->What would you use them for?
-8b) for semaphores which do not allow to unblock multiple waiters
-in a single call to post/release (e.g. POSIX realtime semaphores -
-<semaphore.h>)
-8c/8d) for WinCE prior to 3.0 (WinCE 3.0 does have semaphores)
-ok. so, which one is the 'final' algorithm(s) which we should use in
-pthreads-win32??
-regards,
-alexander.
-----------------------------------------------------------------------------
-Louis Thomas <lthomas@arbitrade.com> on 02/27/2001 05:20:12 AM
-Please respond to Louis Thomas <lthomas@arbitrade.com>
-To:   Alexander Terekhov/Germany/IBM@IBMDE
-cc:   rpj@ise.canberra.edu.au, Thomas Pfaff <tpfaff@gmx.net>, Nanbor Wang
-      <nanbor@cs.wustl.edu>
-Subject:  RE: FYI/comp.programming.threads/Re: pthread_cond_* implementatio
-      n questions
-Sorry all. Busy week.
-> this insures the fairness
-> which POSIX does not (e.g. two subsequent broadcasts - the gate does
-insure
-> that first wave waiters will start the race for the mutex before waiters
-> from the second wave - Linux pthreads process/unblock both waves
-> concurrently...)
-I'm not sure how we are any more fair about this than Linux. We certainly
-don't guarantee that the threads released by the first broadcast will get
-the external mutex before the threads of the second wave. In fact, it is
-possible that those threads will never get the external mutex if there is
-enough contention for it.
-> e.g. i was thinking about implementation with a pool of
-> N semaphores/counters [...]
-I considered that too. The problem is as you mentioned in a). You really
-need to assign threads to semaphores once you know how you want to wake
-them
-up, not when they first begin waiting which is the only time you can assign
-them.
-> well, i am not quite sure that i've fully understood your scenario,
-Hmm. Well, it think it's an important example, so I'll try again. First, we
-have thread A which we KNOW is waiting on a condition. As soon as it
-becomes
-unblocked for any reason, we will know because it will set a flag. Since
-the
-flag is not set, we are 100% confident that thread A is waiting on the
-condition. We have another thread, thread B, which has acquired the mutex
-and is about to wait on the condition. Thus it is pretty clear that at any
-point, either just A is waiting, or A and B are waiting. Now thread C comes
-along. C is about to do a broadcast on the condition. A broadcast is
-guaranteed to unblock all threads currently waiting on a condition, right?
-Again, we said that either just A is waiting, or A and B are both waiting.
-So, when C does its broadcast, depending upon whether B has started waiting
-or not, thread C will unblock A or unblock A and B. Either way, C must
-unblock A, right?
-Now, you said anything that happens is correct so long as a) "a signal is
-not lost between unlocking the mutex and waiting on the condition" and b)
-"a
-thread must not steal a signal it sent", correct? Requirement b) is easy to
-satisfy: in this scenario, thread C will never wait on the condition, so it
-won't steal any signals.  Requirement a) is not hard either. The only way
-we
-could fail to meet requirement a) in this scenario is if thread B was
-started waiting but didn't wake up because a signal was lost. This will not
-happen.
-Now, here is what happens. Assume thread C beats thread B. Thread C looks
-to
-see how many threads are waiting on the condition. Thread C sees just one
-thread, thread A, waiting. It does a broadcast waking up just one thread
-because just one thread is waiting. Next, before A can become unblocked,
-thread B begins waiting. Now there are two threads waiting, but only one
-will be unblocked. Suppose B wins. B will become unblocked. A will not
-become unblocked, because C only unblocked one thread (sema_post cond, 1).
-So at the end, B finishes and A remains blocked.
-We have met both of your requirements, so by your rules, this is an
-acceptable outcome. However, I think that the spec says this is an
-unacceptable outcome! We know for certain that A was waiting and that C did
-a broadcast, but A did not become unblocked! Yet, the spec says that a
-broadcast wakes up all waiting threads. This did not happen. Do you agree
-that this shows your rules are not strict enough?
-> and what about N2? :) this one does allow almost everything.
-Don't get me started about rule #2. I'll NEVER advocate an algorithm that
-uses rule 2 as an excuse to suck!
-> but it is done (decrement)under mutex protection - this is not a subject
-> of a race condition.
-You are correct. My mistake.
-> i would remove "_bTimedOut=false".. after all, it was a real timeout..
-I disagree. A thread that can't successfully retract its waiter status
-can't
-really have timed out. If a thread can't return without executing extra
-code
-to deal with the fact that someone tried to unblock it, I think it is a
-poor
-idea to pretend we
-didn't realize someone was trying to signal us. After all, a signal is more
-important than a time out.
-> when nSignaled != 0, it is possible to update nWaiters (--) and do not
-> touch nGone
-I realize this, but I was thinking that writing it the other ways saves
-another if statement.
-> adjust only if nGone != 0 and save one cache memory write - probably much
-slower than 'if'
-Hmm. You are probably right.
-> well, in a strange (e.g. timeout test) program you may (theoretically)
-> have an overflow of nWaiters/nGone counters (with waiters repeatedly
-timing
-> out and no signals at all).
-Also true. Not only that, but you also have the possibility that one could
-overflow the number of waiters as well! However, considering the limit you
-have chosen for nWaitersGone, I suppose it is unlikely that anyone would be
-able to get INT_MAX/2 threads waiting on a single condition. :)
-Analysis of 8a:
-It looks correct to me.
-What are IPC semaphores?
-In the line where you state, "else if ( nWaitersBlocked > nWaitersGone ) {
-// HARMLESS RACE CONDITION!" there is no race condition for nWaitersGone
-because nWaitersGone is never modified without holding mtxUnblockLock. You
-are correct that there is a harmless race on nWaitersBlocked, which can
-increase and make the condition become true just after we check it. If this
-happens, we interpret it as the wait starting after the signal.
-I like your optimization of this. You could improve Alg. 6 as follows:
----------- Algorithm 6b ----------
-signal(bAll) {
-  _nSig=0
-  lock counters
-  // this is safe because nWaiting can only be decremented by a thread that
-  // owns counters and nGone can only be changed by a thread that owns
-counters.
-  if (nWaiting>nGone) {
-    if (0==nSignaled) {
-      sema_wait gate // close gate if not already closed
-    }
-    if (nGone>0) {
-      nWaiting-=nGone
-      nGone=0
-    }
-    _nSig=bAll?nWaiting:1
-    nSignaled+=_nSig
-    nWaiting-=_nSig
-  }
-  unlock counters
-  if (0!=_nSig) {
-    sema_post queue, _nSig
-  }
-}
----------- ---------- ----------
-I guess this wouldn't apply to Alg 8a because nWaitersGone changes meanings
-depending upon whether the gate is open or closed.
-In the loop "while ( nWaitersWasGone-- ) {" you do a sema_wait on
-semBlockLock. Perhaps waiting on semBlockQueue would be a better idea.
-What have you gained by making the last thread to be signaled do the waits
-for all the timed out threads, besides added complexity? It took me a long
-time to figure out what your objective was with this, to realize you were
-using nWaitersGone to mean two different things, and to verify that you
-hadn't introduced any bug by doing this. Even now I'm not 100% sure.
-What has all this playing about with nWaitersGone really gained us besides
-a
-lot of complexity (it is much harder to verify that this solution is
-correct), execution overhead (we now have a lot more if statements to
-evaluate), and space overhead (more space for the extra code, and another
-integer in our data)? We did manage to save a lock/unlock pair in an
-uncommon case (when a time out occurs) at the above mentioned expenses in
-the common cases.
-As for 8b, c, and d, they look ok though I haven't studied them thoroughly.
-What would you use them for?
-    Later,
-        -Louis! :)