MB> All of this having been said, I still do not understand why the LOCK 
 MB> instruction prefix buys you anything.  Ordinary


 LOCK
 Lock the Bus

 +---+---+---+---+---+---+---+---+---+
 | O | D | I | T | S | Z | A | P | C |
 +---+---+---+---+---+---+---+---+---+
 |   |   |   |   |   |   |   |   |   |
 +---+---+---+---+---+---+---+---+---+

 Locks out other processors during execution of the next instruction. This
 instruction is a prefix. It usually precedes an instruction that modifies a
 memory location that another processor might attempt to modify at the same
 time. See Intel documentation for details on multiprocessor environments.

 ---------------------------------------------------------------------------
 +-----------+
 | 11110000  |
 +-----------+

 Syntax                Example                   Clock Speed
 --------------------+-------------------------+----------------------------
                     | lock  xchg ax,sem       | 88/86     2
 LOCK  instruction   |                         |   286     0
                     |                         |   386     0
 --------------------+-------------------------+----------------------------

 MB> synthesize semaphores, when they are provided to you 
 MB> in perfectly safe form by the operating system, seems 
 MB> sort of foolish to me.

Speed -- Cset++'s _fastsem's use a combination of lock/local mem and system
sems to produce very fast sems.  The system sem is used when a collision
occurs.

 Area Os2prog, Msg#884, Apr-13-94 04:02:18
    From: Anonymous
      To: *
 Subject: fast semphores


 Recently,  someone was inquiring about the "fast semaphores" that the IBM
 Cset++ runtime library uses internally.   I was able to hack this (use at
 your own risk):

  #include 
  #include 
  #include 
  #include 
  #include 
  #define INCL_NOPMAPI
  #define INCL_DOS
  #include 

  typedef struct _fastsem {
      long cnt;
      long hev;
      long hmtx;
  }FASTSEM;


  #if 1
      int _CreateSem(FASTSEM *, int StateOwned);
      int _RequestSem(FASTSEM *);
      int _ReleaseSem(FASTSEM *);
      int _CloseSem(FASTSEM *);
  #else   // use these to see it fail:
      #define _CreateSem(x, y) 0
      #define _RequestSem(x)   0
      #define _ReleaseSem(x)   0
      #define _CloseSem(x)     0
  #endif


  static FASTSEM gFSem;
  static volatile int flag = 0;


  void Thread2(void *ignore)
  {
      int rc;
      for(;;){
          rc = _RequestSem(&gFSem);
          assert(!flag);  // if flag is set,  there was a collision
          flag++;
          if(rc){
              printf("error %d from _ReQuestSem\n", rc);
              exit(1);
          }
          DosSleep(0L);
          flag--;
          rc = _ReleaseSem(&gFSem);
          if(rc){
              printf("error %d from _ReleaseSem\n", rc);
              exit(1);
          }
          printf("Thread %d had it\n", *_threadid);
      }
  }

  int main(void)
  {
      int rc;
      rc = _CreateSem(&gFSem, 0);
      if(rc){
          printf("error %d from _CreatSem\n", rc);
          exit(1);
      }
      _beginthread(Thread2, NULL, 0x2000, NULL);
      _beginthread(Thread2, NULL, 0x2000, NULL);
      _beginthread(Thread2, NULL, 0x2000, NULL);
      _beginthread(Thread2, NULL, 0x2000, NULL);
      _beginthread(Thread2, NULL, 0x2000, NULL);
      _beginthread(Thread2, NULL, 0x2000, NULL);
      _beginthread(Thread2, NULL, 0x2000, NULL);
      getchar();
  }

 Bench Test
 ==========

 A program was written to Request/Release a semaphore 500,000 times.  Three
 types of sems were tested:

     1) 16 Bit OS/2 1.x Ram Semaphores
     2) 32 bit anonymous mutex sempahorees
     3) The Cset++ fast semaphores.

 Results (time in milliseconds; faster is better)
 ================================================

 16 bit (running under OS/2 1.x) : 6125
 16 bit (running under OS/2 2.x) : 3281
 32 bit mutex                    : 11937
 32 bit cset                     : 1000

 All of these sems are fast,  considering the number of iterations.


--- Maximus/2 3.00